Slashdot Mirror


MySQL AB Calls v4.1.7 Production Ready

puppetman writes "MySQL announced a few hours ago that 4.1 has been deemed production ready with the release of 4.1.7. The major enhancements of 4.1 include sub-selects, faster communication between client and server (thanks to parameter binding), replication over SSL, and lots more. A full list can be found here. Time to rehash those tired arguments about why MySQL is not a real database, and (Postgres/Oracle/SQL Server/Access/SAPDB/Ingres/etc) is the only real database out there."

3 of 59 comments (clear)

  1. Re:Production ready? by zatz · · Score: 4, Informative

    Sure, just use the InnoDB storage engine.

    --

    Java: the COBOL of the new millenium.
  2. Greater than 20, less than 99 by ttfkam · · Score: 4, Informative
    • Schemas
    • Views
    • Rules
    • Check constraints
    • Domains
    • Triggers
    • Custom datatypes
    • Stored procedures in no less than five different programming languages
    • Geometric/spatial datatypes and indexes
    • Real type safety
    • Errors when the alternative is data corruption
    • No silent failures
    • Enforcing a difference between NOT NULL and DEFAULT directives
    • Consistent foreign key enforcement (Target table must also be InnoDB, ON UPDATE does not allow recursive updates on the same table, out of range violations, brain dead implementation of NO ACTION)
    • Better transition to Oracle (closer feature parity)
    • Substandard transaction support (The time required to roll back a transaction increases in proportion with the number of operations performed during that transaction; Any non-InnoDB tables referenced in the transaction will not rollback)
    And have they fixed the bug where CREATE INDEX, DROP INDEX, and most ALTER TABLEs rebuild the whole InnoDB table? It's been a year.

    And how about bugs like this (http://bugs.mysql.com/bug.php?id=5670) where creating an index destroys the table. Nice.

    --

    - I don't need to go outside, my CRT tan'll do me just fine.
  3. Re:Have its developers' attitudes changed? by ttfkam · · Score: 4, Informative
    Does Postgres still make really bad optimizer choices if the data-types being compared aren't identical? Last I checked.
    At least there's a workaround. You can always explicitly cast your value to the type in question. I don't know of any similarly straightforward workarounds for the data manipulation/loss bugs in MySQL.
    --

    - I don't need to go outside, my CRT tan'll do me just fine.