Poo-tee-weet

MySQL enjoying its new home

Lukas Kahwe Smith — Fri, 09 May 2008 08:16:51 +0200

So it seems that Sun has made it clear that the core product will remain open source. Of course the definition of what is core and what isn't is up to Sun/MySQL to decide, but it seems that overall more things will be released as open source than if MySQL would have gone through with its planned IPO. So this is a good thing. Speaking of non core products, I really like what Mike and his team are doing in the GUI department with the workbench and their other GUI tools. However since Sun is friendly to PostgreSQL and actually also distributes SQLite (its bundled with Solaris after all), I wonder if they are considering making their tools more and more portable across other RDBMS?

Signup for the TestFest@Webtuesday

Lukas Kahwe Smith — Wed, 07 May 2008 13:34:16 +0200

As I already noted on the Liip blog, there will be a TestFest as part of the Webtuesday Hackday. So in order to better prepare things for the event I would appreciate it if people interested in joining the TestFest drop me a note via email or in a comment. See you there!

Finding the right place for a join condition

Lukas Kahwe Smith — Wed, 30 Apr 2008 12:03:20 +0200

In a little app where users can create tabs and portlets in those tabs I ran into some issues with my ordered list implementation. It turns out I just misplaced a filtering expression in the WHERE clause instead of the JOIN condition. The basic idea was that I wanted to add new portlets in the left hand column at the top. The positions from the portlets actually start at 0, but what I am doing is to insert them at 1 below the current minimum or -1 if the table is empty. Then in a second query I push everything up by one. Seemed like the most efficient way to deal with concurrency. I guess in theory I could even skip pushing things up by one, but oh well.

Here is the original query (note that I am using PDO which supports Oracle style named placeholders for all drivers including MySQL):

INSERT INTO user_tab_portlets (tab_id, portlet_id, pos, col, is_open, config)
            (SELECT :tab_id, :portlet_id, COALESCE(MIN(utp.pos)-1, -1), :col, :is_open, :config
                FROM user_tabs ut LEFT JOIN user_tab_portlets utp ON (ut.id = utp.tab_id)
                WHERE ut.id = :tab_id AND (utp.col IS NULL OR utp.col = :col)
                GROUP BY utp.tab_id, utp.col)

I sort of expected the "utp.col IS NULL OR utp.col = :col" to work out fine for the case when there are no portlets yet in the left column on the given tab, since due to the LEFT JOIN the "IS NULL" part should fire (the col is not nullable). As it turns out a more readable and actually working version of my query would look like this:

INSERT INTO user_tab_portlets (tab_id, portlet_id, pos, col, is_open, config)
            (SELECT :tab_id, :portlet_id, COALESCE(MIN(utp.pos)-1, -1), :col, :is_open, :config
                FROM user_tabs ut LEFT JOIN user_tab_portlets utp ON (ut.id = utp.tab_id AND utp.col = :col)
                WHERE ut.id = :tab_id
                GROUP BY utp.tab_id, utp.col)

Anyways, if anyone has some pointers on how to better do an ordered list in SQL please let me know. I felt quite good when I figured this one out :)

Dear Marten,

Lukas Kahwe Smith — Fri, 18 Apr 2008 08:20:40 +0200

So now that you have posted some clarifications on what is going on exactly, it seems like there is less of a problem as original thought. However I must say that the the replies you posted on Jeremy's blog (and later mine as well), you let me to believe that things are quite bad indeed. Only now that I see your two posts on /, I can relax a bit again. Matthew has written a very good summary of the situation with some historical background.

I guess its great that you take the time to post on the blogs of individual community members, but next time you might want to take a bit more care on what you post. For example in my post I explicitly asked to be corrected if I misunderstood what's going on. When you posted in my blog without correcting me, I assumed that I was right with my assessment of the situation. Also I am a bit concerned about how you compare MySQL's business model with PostgreSQL, because I think they do not really compare well (at least from a community perspective), though Josh predicted back when I posted my thesis paper on exactly this topic, that MySQL is moving towards the PostgreSQL eco systems "secret sauce" business model.

So where are we at? It seems that Sun/MySQL is considering close sourcing now yet developed code that provides implementations for plugins against some of the new pluggable API's. This reduces concerns since this way the chances of things diverging between the "real community" (more on this in the next paragraph) and Sun/MySQL internal development. More importantly it means that community users can easily load community developed alternative implementations without much hassle. I have not examined the plugin API's in detail, but from what I read they all loading of plugins without a restart. That being said its still likely that most hosters will not allow average users to load new modules, but I am not sure how that will play out and how much work there has been done to make it safe for hosters to allow this. So as long as the proprietary extensions focus around plugins against clearly defined plugin APIs, I see little problem from the perspective of the community. If this makes business sense is another story.

But there is still some concern that I have with Marten's comparisons made in regards to the PostgreSQL eco system. To me the key difference between their eco system and MySQL's is that MySQL does not have a true "community" version. MySQL AB and now Sun decides on what goes into the "Community Edition". More over its exactly the same company that also employ all of the key developers, so there isn't really someone outside of Sun/MySQL that could reasonably decide what should go in. Of course there could be community votes, but this is also not how open source works. For the most part the core group around an open source projects act like benevolent dictators that make decisions based on a mixture of personal needs and the goal to keep the project alive as open source.

There is this delicate trust balance that end users put into the lead developers of the open source products they use. For example look at all the complaints that Zend has gotten for having developed a closed source byte code cache. Ever since then people have said that this should be part of PHP itself, but Zend is stopping this from happening. Even today after years of having an open source solution available that is even run by Yahoo on their servers, we still do not have a PHP release with a bundled byte code cache. However Zeev has given his blessing to bundeling APC with PHP6. Is it Zend's fault that it took this long? Did Zend do enough for PHP that it was ok to give them this money making opportunity? However the key point is that the community "gave" Zend this opportunity, because there are enough non Zend people in the core development team. Again the situation is totally different at Sun/MySQL.

Maybe if Sun/MySQL would make it really transparent that its the MySQL developers that decide on what gets into the Community Edition with no influencing at all by managers, this could ensure that this trust balance is not thrown out of wack so easily in the future. If there would be a public promise that the community, and more importantly Sun/MySQL developers could fallback upon, it could a long way. So when there is an open source alternative implementation to a MySQL product, that someone is willing to contribute to the Community Edition (which will of course require that people grant MySQL the right to release the same code under a proprietary license - which in the sense is quite comparable to releasing code under the BSD license that PostgreSQL uses), and the code is good, then its the Sun/MySQL developers that decide what goes in and not the managers. Of course my assumption is that their decision will be based on love for the open source project they are working on and not the development of their stock options. Then again like I said earlier, open source developers always make their decisions at least partially out of selfish reasons and that is fine and dandy.

Maybe Sun can teach MySQL a lesson about open source?

Lukas Kahwe Smith — Wed, 16 Apr 2008 14:56:19 +0200

Once again Jeremy weights in on the oddity called "MySQL Enterprise Edition". This time around it seems that Sun/MySQL is moving towards making their Enterprise Edition more proprietary by including features that will never be available in the Community Edition. Not sure, but I guess they are also not providing the source to the general public (I do not remember all the details of the continued mumbo-jumbo saga surrounding this product, but maybe they already pulled the source from the public version a while ago - please correct me here). I do assume that paying customers will still get the source, though obviously not under an open source license.

As before MySQL AB illustrates that they have stop believing in open source when it becomes time to make money. I was not all up in arms about this with stuff like the Monitor or the Workbench (heck I use a proprietary editor, though they are moving towards open sourcing more, rather than less of the new features - similar model though as Workbench), but I do think that hot backup should be part of the core product as is the case in other OSS databases like PostgreSQL. InnoDB hot backup is a bad comparison for Marten to use here. Nobody is claiming that its not possible to write reliable solid proprietary software. What people are saying however is that this is not the best way to write software, especially if you are an organization that has (should have?) open source build into its DNA (both from the business model as well as from the people you employ to the people that use your software). Also the comparison Marten makes in the same post about PostgreSQL is also off. The fact is that even if alot of companies in the PostgreSQL community are proprietary, its still a community decision what is added to the common base PostgreSQL. With MySQL the community does not have this option unless it does a proper fork, which I doubt Sun/MySQL is all to interested in seeing. Anyways, of course as a paying customer I would also appreciate wide spread testing of such a critical feature as backup is, but alas I will be stuck with MySQL AB's less than stellar internal QA to ensure that my backups will actually work when it becomes time to restore them.

Now the weird thing is that Sun is open sourcing software left and right as Peter also points out. Its a key decision that Jonathan does not get tired explaining. They keep talking about the great divider in the industry being those companies that sell software and those that do not. So I can only guess that this decision predates the Sun merger and was made by the same guys that cooked up the client lib license change (which MySQL sort of fixed), the creation of the Enterprise Edition .. this leaves the door open for some of the new owners to correct this mistake. So maybe we will have the opportunity to witness firsthand how MySQL AB's guys learn from Sun (instead of the other way around as the MySQL guys keep proclaiming).

[Update 16/04/2008 16:14 CEST]
Need to learn how to spell peoples names .. like "Marten" .. sorry about that.