Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Article Poll

Poll I found this article to be
Very Helpful
Not Helpful
Not Very Helpful
[ Results | Polls ]
Comments:0 | Votes:0

Can Slash 2.2.x work with MySQL Max 4.0?

posted by Krow on 11:10 AM February 13th, 2002   Printer-friendly   Email story
Hi there. Over at geekizoid (no, we don't have our front page up yet, yes we are working on it) we are exploring the possibility of moving to MySQL Max 4.0 to get the additional features (like row level locking) that it offers. This seems to scale better (take a look at the discussion on K5 to see what I'm talking about.) I'd like to be able to do it just for the scoop sites we host (we do both slash and scoop hosting, yes there will be a YASS at some point, but we want to get the graphics and small shiny objects finished first), but I don't want to do it if slash won't play well with it. Yes, I know it's alpha level code and might eat Taiwan. Still, row level locking could be seriously cool, right? What do you guys think?
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login
Loading... please wait.
  • I've not tested Slash with 4.0 because is really not ready for testing yet. It is very alpha and should not be used ona production site.

    Slashdot does use the Inno tables though. They scale very well.

    So, MySQL Max 3.23.X yes, 4.X, if you don't care about your data.

    You can't grep a dead tree.
    • Does 3.23.X have row-locking?

      "How about you interface with my ass? By biting it!" --Bender
      • If you use Inno tables then yes. Has foreign key and transaction support too.

        It solved a lot of problems the Slashdot had.

        You can't grep a dead tree.
        • I concur.

          I'm a bit late on this one, since nobody had mentioned anything to me about MySQL 4.x. Either way, I'm against it at this point. Mainly because the bottleneck is not with our MySQL server, it's with bloated httpd procs.

          Slash and scoop together with multiple sites requires a horrendous amount of resources. And I care about the data.

          One future, two choices. Oppose them or let them destroy us.