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."
Re:From the article.... (Score:2, Interesting)
And no, creating a function to handle it as an exception is not a real solution.
-- Barbie
Re:You have nothing to fear. (Score:5, Interesting)
I am simply not so optimistic. I am extremely wary of what Oracle will do. Sun was a positive. Oracle is a negative. I think by now, they are feeling the backlash of their previous missteps but that does not mean they have learned their lesson. If there's one thing I know about this type of business and that type of businessman is that once they set their mind on something, they are going to do it whether or not it is in their best interests. What they will do is back off, slow down or approach the end result from another direction. In the end, it will be the same.
OpenOffice.org will become something we don't want. MySQL will be used as a tool until it manages to kill the competition and it will get dropped. Java is already getting screwed up and over. VirtualBox? I'm afraid to even think about it... I love VirtualBox. I used to pirate VMWare Workstation, but I simply like VB better. I don't want to switch back.
I don't like Oracle. I never did. It will take some REALLY surprising things for Oracle to change my mind about them and I seriously doubt they are interested in what I think of them.
Re:From the article.... (Score:4, Interesting)
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
Re:From the article.... (Score:2, Interesting)
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]
Re:From the article.... (Score:4, Interesting)
You think you're smarter than the people working on PostgreSQL, Oracle DB, and other databases (SQL relational or otherwise) known for their ACID properties?
You think writing your own server will provide 100% data integrity?
First, if I wouldn't need to implement all the features - just the ones I want, the job would be a lot simpler.
And yes, I *have* written multi-threaded servers - in c - and they run for months at a time without losing one byte of memory, and without having to kill off threads to reclaim memory lost from leaks.
So yes, if I had to, and someone was willing to pay for it, I could write a server to do a specific job, which is not the same as writing a general-purpose rdbms.
But that's neither here nor there - mysql is good enough for many tasks, so I use it.
Re:Why not Firebird? (Score:5, Interesting)
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.
Re:From the article.... (Score:4, Interesting)
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.
Re:From the article.... (Score:5, Interesting)
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.
Re:You have nothing to fear. (Score:4, Interesting)
That's only the half of it.
You also have the people who took one look at Access and thought "Eeks, that's scary". They decided to work in Excel instead. Since that day, they have encompassed the business logic of an entire department in a spreadsheet (and almost certainly put in so much effort to understanding Excel that it would actually have been easier to learn a proper programming language, but that's not the point. They're not a programmer and they don't want to be one!)
Anyone who's been in IT support/management for any length of time has at least one Access/Excel related war story.
Re:You have nothing to fear. (Score:5, Interesting)
Anyone with experience building enterprise applications can tell you that the hard part is NOT the writing of the code. Most database-driven applications work similarly. The hard part is gathering requirements from non-technical people. What you'll find in any sizeable business is that the knowledge of the business process is distributed among many people. You have to become the expert. I like to model the activity on paper, and then interview people to walk through their jobs with them. The hardest part is trying to decide what parts of the business process are wasteful traditions, and which parts are essential. You may find many subtleties in people's work, the importance of which is not discovered until much later. Good notes are essential.
Anyway, back to Access-- with Access, I can literally have someone sit next to me as I mockup a WORKING demo. When they see it working the way they want, and they walk out, I can rip it apart and do things the right way. On a recent project, I did this, and it finally got the software off the ground. The problem was that the requirements were changing too fast. The original developer had written something in PHP, but every time he was asked to change something, the result was weeks of agonizing bugfixes. We switched the frontend to Access, keeping the data in MySQL (we used the MySQL ODBC connector). Now that the software has matured, and the pace of changes has slowed, developers can replace Access with something like Rails. Access is a great tool if you want to rapidly beta-test your application. I've tried other rapid development frameworks (Rails, CakePHP, and
Microsoft put a lot of thought into the GUI design features of Access. I have yet to find something that works as well, or as quickly. You're right, it's not a "real" database, but it can be *attached* to a real database. Microsoft gets a lot of crap (rightly) for their software that sucks, but Access is not in that category.