Slashdot Mirror
MySQL to Adopt Solid Storage Engine
hmart writes "As seen on ZDNet's Open Source Blog MySQL is taking another step to defend from Oracle's recent acquisitions of InnoBase and Sleepycat. From the article: 'MySQL responds by getting Solid Information Technology, a proprietary database vendor, to take its solidDB Storage Engine for MySQL open source, under the GPL, starting in June.'"
No matter which storage engine you use in MySQL, the SQL syntax is still the same. All you have to change is the ENGINE= line in your schema definitions.
Oh, I doubt that there is a single MySQL developer who would be offended. We are not so aloof that we cannot take criticism - actually we welcome constructive criticism, it lets us know what needs to be improved.
Perhaps we have been a bit lazy: Assuming that the partnership with Innobase would continue forever and that MySQL would eventually acquire Innobase.
MySQL has a few advantages - it is a small company which can react quickly to unexpected changes. We learn. Jim Starkey has joined us - he is a veteran of relational database designs and a delight to work with - and we do plan to have our own storage engines with transactional goodness, we already have Cluster but we need something more lightweight usuable by everyone.
In the meanwhile, it is good to take advantage of the MySQL architecture and make partnerships which can make use of one of our strengths. Having 3rd party storage engines is something which has been quietly encouraged for many years and is now something I think will see more publicity.
(disclaimer: opinions are my own and not of my employer nor anyone else)
No sig. Move along - nothing to see here.
If your application is designed for MySQL specificially without strict mode, then strict mode is not for you. It is more useful to people porting their applications from some other product to MySQL than to the existing MySQL user base.
Ditto above. Perhaps the existing MySQL user wants to go to strict mode in order to support databases *other* than MySQL. Have you concidered that?
MyISAM was never designed with transactions in mind. It performs its intended function excellently. Not all data is useful to keep in some kind of transaction context - take for example a table mapping UPC codes to product names and descriptions: it will never need to change in a transaction so having transactional overhead would be wasteful.
Myth used to scare people away from opensource GPL code.
Some people would disagree with that statement. Quite a lot of people have found that for their needs, MySQL is lighter and faster (or at least, as fast as the big name products) even when never using MyISAM tables.
There will be people whose needs are best served with products from Oracle, IBM, Microsoft, Sybase... I am sure that no one in MySQL claims that it is the only solution to all problems: MySQL is a young database product which is actively being developed so it will improve.
No sig. Move along - nothing to see here.
The problem being once these important OSS coders see oracle source, they are tainted. Any further OSS contributions will have to be heavily scrutinized for IP violations.
Yes and no.
Strictly speaking, there is no such thing as a "tainted" developer. There are three different forms of IP law that Oracle might try to use to control what the programmers do after they leave the company:
So, if the developer has access to a good lawyer, it seems like Oracle really can't do much to prevent future work. But, of course, a wealthy corporation can afford legal battles much better than an indiviudal can, and any or all of the above would lend enough credibility to a lawsuit by Oracle that the coder might end up having to fight it in court... which can be really expensive even if you win. Then again, this is exactly the sort of case where the EFF and others would probably be willing to step in and help out.
Finally, if Oracle failed to terrorize the devs into meekly going along, Oracle probably wouldn't want to go to court very much. Not only is it bad PR, but it does cost a lot of money, even if you're a corporation with deep pockets. There has to be a reasonable expectation that the cost is worth the result, which seems pretty unlikely. Threatening a lawsuit you probably can't win doesn't cost much, but actually pursuing one does.
So oracle does not need to keep them. They just need to expose them to even bits of their db source, and they have tainted the coder.
No, I really don't think that's enough. What they really need to do is to terrify the coder with weighty, frightening non-disclosure agreements and non-compete agreements. If they do too much of that, though, they won't get the hire in the first place.
Of course, IANAL. But I have read the relevant law, and have some familiarity with the applicable precedents, thanks to other cases.
I really hope that the open source developers who've gone to work for Oracle have run their employments contracts past attorneys of their own.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.