Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Oracle

Oracle Releases MySQL 5.5 263

darthcamaro writes "Two years after Sun released MySQL 5.1, Oracle has picked up the ball with the official release of MySQL 5.5. New features include semi-synchronous replication, InnoDB by default and new SIGNAL/RESIGNAL support for exception handling. Above all, Oracle stressed that they are committed to further MySQL open source development and that they see it as a complementary technology to their proprietary Oracle database."
This discussion has been archived. No new comments can be posted.

Oracle Releases MySQL 5.5

Comments Filter:
  • by tautog ( 46259 ) on Wednesday December 15, 2010 @08:38PM (#34569250)

    You can trust us. Honest.

  • by Pharmboy ( 216950 ) on Wednesday December 15, 2010 @08:40PM (#34569260) Journal

    From the article: There were concerns about how the open source database would fare under Oracle's leadership, but those concerns are now being put to rest by Oracle with the release of MySQL 5.5

    Um, no, not all concerns are put to rest. This was a pretty fluffy piece of journalism, just quotes and feel good words. I'm glad that MySQL has moved up a notch, but I'm still looking really hard at PostgreSQL as a possibility in the long run.

    • Re: (Score:2, Interesting)

      by tomhudson ( 43916 )
      Until PostgreSQL gets ON DUPLICATE KEY support, it's off the table (pardon the pun). ON DUPLICATE KEY is just so handy, and solves so many problems, that it's amazing most people aren't using it.

      And no, creating a function to handle it as an exception is not a real solution.

      -- Barbie

      • Unless you are trying to do anything that involves subqueries. Hopefully they fixed it, but subqueries couldn't be used in views, and would often be executed slower than running the queries separately and typing the answers from one query into another.

        Also taking the silent data truncation errors, MySQL isn't exactly a highly reliable database.

        • by tepples ( 727027 )
          I develop LAMP based retail warehouse automation software at work. I've generally used a workaround of realizing subqueries in temporary tables.
      • by nxtw ( 866177 )

        Until PostgreSQL gets ON DUPLICATE KEY support, it's off the table (pardon the pun). ON DUPLICATE KEY is just so handy, and solves so many problems, that it's amazing most people aren't using it.
        And no, creating a function to handle it as an exception is not a real solution.

        Depending on an inferior database for a trivial feature creates more problems than it solves.

        If insert or replace with a single SQL statement is such an important feature, you could make a stored procedure.

        • by tomhudson ( 43916 ) <barbara.hudson@b ... com minus distro> on Wednesday December 15, 2010 @09:10PM (#34569492) Journal
          As I pointed out, this is something that is so OBVIOUS in retrospect that it's a wonder other database products haven't gotten around to implementing it.

          I know it's fashionable to rag on Oracle nowadays, but we've seen this with Sun as well - where one hand doesn't know exactly what the other is doing, or parts act in conflict.

          MySQL has the features I want, including ON DUPLICATE KEY. When pgsql has it, I'll certainly look at it, but unless things change, why bother?

          -- Barbie

          • by nxtw ( 866177 )

            MySQL has the features I want, including ON DUPLICATE KEY. When pgsql has it, I'll certainly look at it, but unless things change, why bother?

            So you don't want data integrity? ACID?

            • by tomhudson ( 43916 ) <barbara.hudson@b ... com minus distro> on Wednesday December 15, 2010 @09:36PM (#34569668) Journal
              If I absolutely needed 100% data integrity, I'd write my own server. And I certainly wouldn't use SQL.
              • Re: (Score:2, Flamebait)

                by afabbro ( 33948 )

                If I absolutely needed 100% data integrity, I'd write my own server. And I certainly wouldn't use SQL.

                ....and your credibility just flew out the window. Data integrity is the mission of SQL relational databases and has been developed with that in mind for nearly 40 years.

                No doubt, something you whip up in your basement will be much better...

              • That might possibly be one of the least intelligent things I've ever read.

                Can you possibly expound on that statement to explain why it makes any sense whatsoever? Or perhaps explain the relationship between SQL and ACID?

                You do realize there are non-SQL ACID solutions already readily available right?

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Or either MySQL or PostgreSQL could implement support for SQL:2008 MERGE syntax which is the appropriate method for handling this scenario, as well as countless others.

          http://en.wikipedia.org/wiki/Merge_(SQL) [wikipedia.org]

      • that's because it isn't needed, the equivalent operations can be done in any SQL compliant database (or for that matter in ISAM and VSAM systems too)

        you're wanting to use a less robust dbms because of your laziness.

        • by tomhudson ( 43916 ) <barbara.hudson@b ... com minus distro> on Wednesday December 15, 2010 @09:34PM (#34569656) Journal

          that's because it isn't needed, the equivalent operations can be done in any SQL compliant database (or for that matter in ISAM and VSAM systems too)

          you're wanting to use a less robust dbms because of your laziness.

          Don't be silly. Sure, there are other ways to do it, but why should I when it "just works" and is easy to explain to others?

          I don't need 100% sql compliance. I need something that does certain things well. Sorry, but postgresql lags in that area.

          You can try to turn this into another vi vs emacs war, but I'm just not interested. I'll continue to use the right too for the job, based on the features *I* need, not some ideological nonsense.

          -- Barbie

          • by h4rr4r ( 612664 )

            Yeah Postgresql trades BS features for reliability and data integrity, clearly just like vim vs emacs. Oh wait no not at all.

            • Re: (Score:3, Informative)

              by tomhudson ( 43916 )
              When's the last time you lost data with mysql that was directly attributable to the database, and not to a messed-up query or a hardware or network problem?

              To hear everyone going on so much, you'd think that you couldn't even run a web site with it.

              Obviously that's not the case, so a LOT of the complaining is just nonsense, same as the vi vs emacs jihads.

              -- Barbie

              • by nxtw ( 866177 ) on Wednesday December 15, 2010 @09:54PM (#34569800)

                When's the last time you lost data with mysql that was directly attributable to the database, and not to a messed-up query or a hardware or network problem?

                On 0000-00-00 00:00:00, of course.

              • I've been a developer and admin on both over the last ten years, two horrendous crashes losing mission critical data with mysql and none yet with postgresql.

                mysql is ok for but I wouldn't build back end for say a medical insurance EDI system on it as I have recently with 18 month project on postgresql 7.3.10

                • by Yaa 101 ( 664725 )

                  It seems you forgot to make a binary safe backup of your database.
                  b.t.w. my tip to you is not to trust PostgreSQL either as it like MySQL is a database server, not a backup method.
                  You wouldn't have lost your mission critical data if you used rsync to put a binary safe copy on (an)other machine(s).

              • by CBravo ( 35450 )

                Exception reported on Wed Dec 15 17:20:02 CET 2010 from ... Cannot query XXX database with query SELECT * FROM YYY Table \'./XXX/YYY\' is marked as crashed and should be repaired at

              • by shish ( 588640 ) on Thursday December 16, 2010 @09:56AM (#34573458) Homepage

                When's the last time you lost data with mysql that was directly attributable to the database

                A couple of years ago (the last time I used mysql), I was running it on a tiny VM, where I found it hit the memory and disk limits quite frequently -- and in each case, the server would crash and leave corrupt tables which required 20-30 mins of fixing. Running postgres in the same situation, out of memory causes a single worker process to die (but you can then reconnect, it's not the whole server that's down), out of disk causes "error, out of disk space" (and you can still make read-only queries).

                Also, running a pretty high load website (>1000 queries/sec) on not-that-great hardware, it seems mysql would randomly drop table indexes when it couldn't keep up with inserts, thus bringing the whole site grinding to a halt. Since switching that site to postgres, it's been a lot more reliable (it's also been faster, since postgres' indexes are better, and it runs straightforward queries better, where I was always contorting queries to avoid mysql performace gotchas, but those aren't really data loss)

              • When's the last time you lost data with mysql that was directly attributable to the database, and not to a messed-up query or a hardware or network problem?

                If you're losing data from queries, then you're the poster child of just how bad MySQL actually is. Furthermore, do some simple searches on your favorite search engine. Or you can just look at your replies. Data loss from MySQL is extremely common. That's exactly why MySQL has such a poor reputation with knowledgeable DBAs and why, in general, DBAs don't like MySQL.

      • You can create a temporary table, fill it up with rows of data and:
        1) INSERT rows not existing from temporary table
        2) UPDATE from temporary table unless INSERT affected all rows
        Ensure you drop temporary table at last.

        If you suspect UPDATE is necessary, you may do #2 first to save on the number of updated rows.
        If you supect UPDATE is not necessary, do #1 first like shown above. If you're paranoid, you may raise exception if UPDATE becomes necessary.
        You may find variations which may be more efficient or simpl

      • by Bacon Bits ( 926911 ) on Wednesday December 15, 2010 @10:50PM (#34570108)

        The ANSI SQL standard way to do this is to create "INSTEAD OF" triggers, which means you're permanently modifying how INSERT works on a given table. ON DUPLICATE KEY means the behavior of the DB ("On INSERT do I error or UPDATE?") is dictated by the query and not the DB schema. That's sloppy. If Bob writes an application that uses the same database as Alice, now he has to use ON DUPLICATE KEY in order to ensure consistent behavior. That's awful.

        • by Sxooter ( 29722 ) on Wednesday December 15, 2010 @11:19PM (#34570264)

          No, the ANSI SQL way to do this is to use MERGE. Unfortunately, pgsql doesn't support that yet. It's on the todo list so I'm sure if someone got out their checkbook and wrote the pg developers a check we'd see it soon enough.

          • Someone did get out their checkbook, which is why MERGE has been under development for months already, with working prototypes [postgresql.org] being tested since late August. The hope is that this makes it into PostgreSQL 9.1, due to be released next summer. Right now trivial cases work, the main bugs found in the last round of review involve concurrency issues that are still being ironed out.

    • Name one ISP where I can get a PostgreSQL database with my account without getting my own server?

      Until that day happens it is Mysql only for me.

      Please someone patch PostgreSQL to handle multiple user accounts so ISPs can switch? That is the only thing holding it back and why ISPs include MySQL

  • by Nefarious Wheel ( 628136 ) on Wednesday December 15, 2010 @08:46PM (#34569332) Journal

    The thing is, Oracle still owns it. Or at least as much as Sun owned it. GPL to the contrary nonwithstanding, who (among the open source community) is going to want to update MySQL, now that it's in Oracle's hands?

    The popular euphemism for that arrangement is "A mature technology".

    Well, maybe it is. But Oracle's product acquisition is like product punctuation, full stop.

    • by gman003 ( 1693318 ) on Wednesday December 15, 2010 @09:36PM (#34569672)
      MySQL is still just as good as it was under Sun. If you don't like whatever changes Oracle makes, fork it. Make your own. Call it LibreSQL if you wish. Until I hear of Oracle actually doing something bad to MySQL, I'm going to keep using it.
      • by h4rr4r ( 612664 ) on Wednesday December 15, 2010 @09:41PM (#34569698)

        I would suggest planning ahead, based on their track record it sure seems like you might one day need to go some place else.

        • by adolf ( 21054 )

          I'd like to suggest that, based on the track record of open-source stuff it sure seems like a fork will happen whenever it is deemed necessary.

        • Planning ahead: If Oracle does something evil: a. stop upgrading. b. either fork and modify or support someone who does.
        • Mariadb, Drizzle...there are already enought mysql forks.

      • by syousef ( 465911 )

        MySQL is still just as good as it was under Sun. If you don't like whatever changes Oracle makes, fork it. Make your own. Call it LibreSQL if you wish. Until I hear of Oracle actually doing something bad to MySQL, I'm going to keep using it.

        If you don't like your life, fork it! Grow wings and fly away to an island paradise.

        For most people, and by that I mean 99.9999% the above is a hell of a lot more realistic a suggestion than forking a codebase like MySQL

  • Yeah right. (Score:5, Funny)

    by Arancaytar ( 966377 ) <arancaytar.ilyaran@gmail.com> on Wednesday December 15, 2010 @09:15PM (#34569520) Homepage

    Oracle is absolutely and steadfastly committed to Open Source, as seen from their admirable interaction with the OpenOffice.org and Java communities.

    • In case of Java Oracle did not do too much which Sun has not started. It is more or less a timely coincidence that Oracle now gets the blame. The entire TCK issue regarding Apache Harmony already was started by Sun in 2006 and the Google lawsuit was pitched by Sun to Oracle as sales argument. Sun already had this idea but not the balls to do it (after all they were the good guys :-) )
      Just to make matters clearer. OpenOffice is a similar situation Sun has dragged things along before the Oracle merger.
      Althoug

  • Why not Firebird? (Score:4, Insightful)

    by spynode ( 1377809 ) on Wednesday December 15, 2010 @09:26PM (#34569606)
    Nobody seems to mention Firebird which is supposedly on hell of a RDBMS. I wonder why it is so unpopular while it offers so much.
    • Re:Why not Firebird? (Score:5, Interesting)

      by Bacon Bits ( 926911 ) on Wednesday December 15, 2010 @10:44PM (#34570078)

      Pretty easy really.

      1) It was originally an embedded or server-less DBMS. That instantly makes devs think "Oh Lord, it's Access!"
      2) It had a large number of security problems at one point (pre v2 era) in the past that went un-addressed for entirely too long.
      3) It uses Interbase Public License (a modified Mozilla Public License) that is not compatible with the GPL... that's really, really bad for an Open Source embedded-style DB.

      It's gotten leaps and bounds better since early versions, but it's never really beaten the early reputation, IMO.

    • by afabbro ( 33948 )

      Nobody seems to mention Firebird which is supposedly on hell of a RDBMS. I wonder why it is so unpopular while it offers so much.

      Ecosystem.

      That's really the answer...so many FOSS apps are coded and developed primarily with MySQL in mind that it's the path of least resistance at this point for FOSS apps. It really has nothing to do with the quality of the code per se...as long as MySQL is "good enough" it will continue to be used.

    • I've actually looked at using Firebird before. It seems to be caught up in the Postgres trap. Postgres is a great RDBMS: Arguablly better than Mysql.

      Question: How many people actually use Mysql as a RDBMS in such a way that it could benifit from the additional features of the more featureful systems?

      Answer: not many.

      Question: How many people are using Mysql because the lack of the features allows it to be faster?

      Answer: All of the large users of mysql: facebook, flickr, google, yahoo, ect.

      If you imagine two

    • by ceeam ( 39911 )

      a) It's less unpopular than you think.

      b) And being "unpopular" is actually a nice feature.

      c) Historical documentation problems. Less of an issue now, but it used to be "lore-based".

      Also, the stricter RDBMS is the more unpopular it will be. You *can't* be as sloppy with it as you can with MySQL (or even Postgres). For starters - because transactions everywhere and case-sensitivity.

    • by 2phar ( 137027 )
      What Firebird does, it does well. The thing is, if you have a choice for a backend server, PostgreSQL really delivers all the same functionality as Firebird, but a whole lot more. Some of the gaps with Firebird are: No inherent replication solution, no GIS support (like PostGIS), more limited range of SQL functions, less language extensibility options (functions in Firebird can be added, but only through writing platform-dependent DLLs), no XML support (dunno if PostgreSQL is much better on XML).
  • Trust me, says the devil.
  • The decline will not be immediate, it will take some time, notably Apache distributions like XAMPP and WAMP will have to offer users alternatives to MySQL, as most developers use these packages, instead of installing products independently. All is not lost, the Open Source community has plenty of options. There are two well established alternatives to MySQL: PostgreSQL and Firebird. Both have large established communities, and support of major corporations. All of these will become the next MySQL

  • ..for a few months on one installation where I needed partitioning. Did not have any crashes/trouble with the beta, but I was running only like 10 different queries in total on this server so it's by no means a comprehensive beta test. Good to see a real release.

"Hello again, Peabody here..." -- Mister Peabody

Working...