MySQL to Get Injection of Google Code

inkslinger77 writes to mention that MySQL has published their software roadmap out through 2009 and it includes an injection of code from Google. Google remains relatively secretive about how their systems work but they are one of the largest users of MySQL. Earlier this year Google signed a Contributor License Agreement which provides a framework for them to contribute code to MySQL. "The search company has done a lot of work customizing MySQL to meet its special needs, which include better database replication, and tools to monitor a high volume of database instances, Axmark said in an interview at MySQL's user conference in Paris. MySQL will include some of those capabilities in future versions of its database, probably in point upgrades to MySQL 6.0, which is scheduled for general availability in late 2008, Axmark said."

"Do no evil!" - Sweet

[y86]

It's nice to see them giving back.

If only Microsoft would give back on all the mods it has made to the Unix tools. Example: http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx [microsoft.com]

Transplant to Postgres?

[Doc Ruby]

I prefer Postgres to MySQL. I wonder whether these MySQL revisions will be generic enough to use to improve Postgres.

I also wish these two databases interoperated more. I'd like to use a MySQL proxy to my Postgres server, so apps depending on MySQL could still work, but use Postgres to actually process the data (or just serve as a master DB for replication). Porting apps between DBs, and huge projects to join across different apps' tables in different types of DB servers should be ancient history. Mixed DB-type clusters might not be high performance, but they'd get the iterative development started, after which performance could be just an optimization, which is the right way to do it anyway.

Re:MySQL?

[Anonymous Coward]

The comment in the article that foreign keys won't be supported until 6.1 speaks for itself. It might not be *crappy* to some but to me this alone makes it quite useless and this admission is only the tip of the iceburg. I sincerly hope that one day MySQL will graduate from the realm of being a toy DB.. That said toy DB's are quite useful for a number of applications, just not any I personally care about.

Wake me up when even a single financial institution uses it for transaction processing.

Good stuff coming out of google

[shmert]

For the Java coders out there, Google is also releasing google collections [google.com], which looks quite nice. There's a new interview here [javalobby.org] with the authors. It's fun stuff to poke around in, and appears to be extremely well-written code.

Once this stabilizes, I'll probably be using it. It's nice to see such a direct impact on my work from their contributions. Thanks guys!

Re:Transplant to Postgres?

[Doc Ruby]

I am in fact using DBI-Link to let Postgres queries connect to data in an LDAP DB. You have good reason to proudly plug the SW :).

You don't know any developers in NYC who would be good for throwing a MySQL datamart up on top of that, would you?

Re:Transplant to Postgres?

[ShieldW0lf]

I've got 86 tables at the moment in my latest project, and 231 stored procedures. It's very easy to manage, very secure, and it's easy to reuse the functionality.

I don't bother using classes to represent the business objects, I just use database views to control the shape of the data that comes back across the stored procedures and pass the properly formatted arrays to another set of functions that generate the appropriate HTML/XHTML/XML as needed.

When it comes time to do caching, I'll have the ability to add that caching to the data layer within the Biz class and to the middle layer within the appropriate view functions as the usage data comes back.

As it scales, I'll have no dirty objects within objects within objects to worry about, just arrays and strings to cache and database replication to set up within Biz.

The database views and stored procedures are the db admins contract with the script writer, while the shape of the various View functions are the script writers contract with the designer. Each role has a great deal of latitude with clearly defined boundaries.

I've written similar systems that used a more object oriented approach, and while it can work well, I've found that either you have the pain in the ass of maintaining an objects clean/dirty state and using lazy writes, or you have the objects operate as a thin layer over a bunch of db functions and you end up with more db traffic than you need. This avoids that completely.

Each their own, but this works well for me.

Re:Hells yeah

[RobBebop]

We don't distribute it, so we aren't required to submit the changes back. We of course, try to contribute back all the changes we possibly can.

Ahh, the Google workaround for the GPL. Selling web-services that RUN Free Open Source Software and NOT selling software. You get to keep the really good changes to yourself. =P

Personally, I'd like to see Google put there code out there as GPL and risk having a meaningful competitor. The benefit of having some really useful software available for high school and college aged kids to learn from would be immeasurable. Also, the transparency and openness of this would be reminiscent of some of the advances made by Bell Labs in the 1970s.