Who to Believe
Now Zack Urlocker, MySQLs vice president of marketing, told me thats not true, from a technical perspective. "From a technical perspective, its the opposite situation," he said. "Part of the reason we have this pluggable storage architecture is it allows you to have higher-level capabilities: the parser, the optimizer, caches, all of the SQL and all of the management services.
"Thats all completely independent of the storage engine. That means replication, metadata, stored procedures, triggers and views are written at a higher level and written independent of storage engines."Robin Schumacher, worldwide director of product management for MySQL, contacted me to explain why Lubets claim is "100 percent false." "All features in the upcoming MySQL 5.0 are not dependent on InnoDB at all," he said. He sent a document that runs through a simple test that "unplugs" InnoDB from the MySQL database server and then demonstrates the creation of three MySQL 5.0 flagship features: a stored procedure, a trigger and then a view. "Moreover, the actual fact is that InnoDB loses a great deal when it is unplugged from MySQL," Schumacher said. "Once detached, InnoDB loses a lot of functionality including replication, robust stored procedures, triggers, views, all SQL functions, data encryption/decryption, actual authentication/privilege support, any GUI management tools interface, data load/unload, and much more," he continued. "Even more painful is that InnoDB loses a great deal of SQL parsing ability (their parser is only 7 percent the size of ours, indicating a great loss in ability to interpret SQL), and a real database optimizer." This is why Innobase came to MySQL in the first place, Schumacher said, and why many of MySQLs partners and customers write storage engines for MySQL: "They get so much functionality by simply plugging a storage engine into our server rather than writing a complete database from scratch," he said. So transaction support will still exist in MySQL, even without InnoDB through its BDB engine, which supports full commit/rollback functionality. Finally, Schumacher said, customers should rest assured that MySQL will always provide bug fixes and enhancements to the server layer where any new features, like those in 5.0, may be used by any MySQL pluggable storage engine. So you can take your pick of who to believe: On one side you have an ex-Oracle employee whos working with a company that competes with Oracle, plus an open-source expert and MySQL user of long standing. On the other side, you have MySQL itself, which, of course, has got to put a sunny face on this. (Id give MySQL the benefit of the doubt when it comes to the importance of InnoDB to the heralded new features in 5.0, given Schumachers input.) Hell, what else can they do? This rabid puppy of a deal came hurtling out of nowhere, dripping with foam. Its certainly not like Oracle called up MySQL to reassure them that things will be hunky-dory after the mergeruntil, that is, after the acquisition was a done deal. "It [wasnt] a surprise in the sense that weve got a multiple storage engine architecture," Urlocker said. "We knew we had a third-party relationship with InnoDB that may or may not last forever." Yes, but for Gods sake, why? Why have a contractual relationship with a company that makes such a core piece of your architecture? Why not just buy them, as the company has done with other important pieces? "I cant comment on past, present or future acquisitions," Urlocker told me. "All I can say is theyve been a good partner in the past and will be a good partner going forward, even as part of Oracle." OK. But dont expect MySQL customers who want to take MySQL 5.0 commercial to be solaced by that, since by doing so they leave the cozy community of GPL and venture out into the icy darkness of having to enter a contract with Oracle, via MySQL, after the current InnoDB contract expires in the coming 18-21 months. This is what Oracle says in its release: "InnoDBs contractual relationship with MySQL comes up for renewal next year. Oracle fully expects to negotiate an extension of that relationship." This is what Lubet, former Oracle sales mistress, has to say about that: "Im pretty sure, as an ex-Oracle employee, that the sentence in the release about Well certainly be happy to renew the contract, that it was written by Larry and that he was laughing out loud as he [dictated it]." As Lubet sees it, Oracle found a flaw in the MySQL business model. It cost virtually nothing for the company to exploit that flaw. And at the end of the day, will Oracle work particularly hard to ensure it helps to keep alive an open-source database that could threaten to eat away at its meat and potatoes revenue streami.e., database licenses and support? At any rate, MySQL has a contract with InnoDB thats in force for some time. That gives MySQL and its community time to plan. At this point, Urlocker told me, MySQL doesnt have any plans to fork the code, but its always an option, if Oracle does something thats perceived as a slap in face. Lets hope that Oracle is up to good. Lets give the company the benefit of the doubt. But just keep in mind, as Lubet pointed out, that Oracles responsible, above all, to its stockholders, not to a little open-source database vendor or its users. Oh, and Oracle? Wasnt in the mood to chat with me about it. Lisa Vaas is Ziff Davis Internets news editor in charge of operations. She is also the editor of eWEEK.coms Database and Business Intelligence topic center. She has been with eWEEK and eWEEK.com since 1995, most recently covering enterprise applications; database technology; and RSS, syndication and blogging technologies. She can be reached at firstname.lastname@example.org. Editors Note: This story was updated to include input from Robin Schumacher. Check out eWEEK.coms for the latest database news, reviews and analysis.
"Thats all completely independent of the storage engine. That means replication, metadata, stored procedures, triggers and views are written at a higher level and written independent of storage engines."