DailyStuff

Door een posting van Hans Wolters werd mijn aandacht eigenlijk getrokken tot hoe Monty aan mijn adres kwam. En bij controle bleek dat Monty mail heeft gezonden naar een adres dat alleen was gebruikt om toegang te krijgen tot sommige documenten bij MySQL. De vraag is dan ook hoe handig Monty bezig is. Want hoe nobel de strijd ook is, er zijn altijd betere manieren om mensen te bereiken dan om een database te gebruiken waarvoor deze overduidelijk niet bedoelt is. Daarbij ook de vraag eigenlijk of de huidige eigenaar van MySQL hiervan op de hoogte was en wat de impact hiervan kan zijn binnen het juridische stelsel in de VS.

Update: Ik ga hier wel een mail naar Sun aan wagen om er achter te komen hoe de vork in de steel zit.

Een jaar geleden kocht Sun Microsystems MySQL AB op en daarmee ook de open source database MySQL. De transitie ging al niet geheel soepel en ook binnen waren er voldoende vragen waarom dit gedaan was aangezien veel engineers binnen Sun Microsystems een voorkeur hadden voor PostgreSQL. Zeker omdat er al een migratie was gestart om van oa Oracle over te stappen naar PostgreSQL voor oa Sun Management Center.

Dit jaar is de dans om Sun Microsystems begonnen met IBM, maar uiteindelijk werd het Oracle die daadwerkelijk Sun wilde kopen. In de VS is al toestemming gegeven, maar de EC heeft aangegeven dat er kanttekeningen zijn. Het is grappig dat veel kanttekeningen gaan over MySQL, maar niemand beseft dat er maar twee leveranciers zijn van taperobots en Sun is er een van.

Het is dan ook toepasselijk dat Monty van MySQL nu begint over dat zijn database mogelijk wordt opgeofferd. Oracle heef InnoDB verder ontwikkelt, maar dit valt niet in de licentie die MySQL met Oracle had over InnoDB. En om heel eerlijk te zijn is dit een dure les dat code inkopen voor een open source product dus slecht kan aflopen. Dit is dus ook waar open source projecten PostgreSQL en SQLite dus verschillen tov MySQL.

Ik gok dat dit een dure les gaat worden voor de wereld die steeds meer is gaan vertrouwen op open source producten ipv open source projecten. De vraag is dan misschien ook wat er gaat gebeuren met bv projecten zoals OpenSolaris, OpenJDK, Glassfish, SugarCRM en nog vele andere. Een collega zei het vrijdag heel toepasselijk dat GPL is sommige gevallen best wel heel erg handig kan zijn. De vraag blijft of MySQL met de Falcon-engine te redden is of dat PostgreSQL voor nieuwe projecten een betere optie is.

SQL has been seen by many as a standard and on paper they are right. In the real world they are far from the truth when you try to make applications work on multiple databases. Who doesn’t remember ODBC as the golden bullet to solve all your database access issues and later on the same with JDBC. Luckily the language has been standardized is 1986 for the first time and they now are working on the 2008 revision which can be bought from ISO if you want to implement this free standard.

But who implements this standard? MySQL, Oracle, Sybase, PostgreSQL, MS-SQL? The question may be more like “who implements what?” and “how?”. Bug 18078 may give a hint in how well vendors are implementing SQL and may give an inside on how big the vendor lock-in really is. But is also gives an inside on how developers are wasting time writing and discussing abstraction layers to let there application like MediaWiki for example run on multiple databases.

Is this the new barrier where the FOSS-community needs to spend time to give proprietary vendors a run for there money? Just like Mozilla pushed Microsoft to accept open standard for the web, or like OASIS did with OpenDocument, or like the XMPP Standards Foundation is doing with instant messaging? Yes, AOL is running to get there AIM/ICQ-network migrated to XMPP so they can compete and communicate with Google Talk. Hopefully time will teach us how we can free us from proprietary only solutions and level the field again. Until then it’s something to work on and check for when using new applications.

Hoewel de core van MediaWiki zelf redelijk goed met verschillende databases om lijkt te gaan is dit niet het geval voor sommige extensies. Zo ook voor de extensie NewestPages waar wordt uitgegaan van MySQL als database en de SQL-query zo geschreven is om op MySQL te draaien.

Helaas is PostgreSQL wat kieskeuriger en klaagt over het feit dat er een “SELECT … LIMIT 0,5″ wordt aangeboden. Gelukkig is er ook een optie om met een SQL-statement beide database te bevragen. De vraag is dan ook waarom niet direct voor “SELECT … LIMIT 5 OFFSET 0″ is gekozen aangezien zowel MySQL 5 als PostgreSQL 8 dit ondersteunen.

De developer heeft een bugreport en patch gekregen om dit structureel op te lossen. Helaas gaat deze functionaliteit niet zonder flinke aanpassingen werken op Oracle aangezien ondersteuning voor oa LIMIT en OFFSET daarin niet aanwezig is. De komende periode maar eens kijken naar welke extensies ook problemen hebben met PostgreSQL als database achter MediaWiki, want ik ga niet meer terug naar MySQL.

PostgreSQL ondersteuning kwam pas met versie 1.12 echt van de grond en met 1.15 voor de deur werd het tijd om verschillende 1.13 installaties te gaan upgraden naar 1.14. Bij een eerste poging om van 1.13 naar 1.14 te gaan gingen de wiki’s blank wat helaas geen mooi gezicht was. Bij het niet kunnen herleiden van het probleem bleef alleen de upgrades naar 1.13.3 en 1.13.4 over. Bij het uitzoeken wat er mis was besloot Oracle om Sun Microsystems over te nemen waarbij de toekomst van MySQL nog onzekerder is geworden. Dit ook omdat MySQL 5.1 onder leiding van Sun ook al niet geheel een positieve ervaring was en MySQL 6 heeft DukeNukem Forever trekjes.

Het werd tijd om in een testomgeving MediaWiki 1.14 op te bouwen met PostgreSQL als achterliggende database-engine. Het overstappen van database-prefixes naar schema’s maakt de DBA in mij ook weer blij nu het wat overzichtelijker is geworden. Zeker omdat PostgreSQL dumps op schema-niveau ondersteunt en met veel verschillende wiki’s is dat wel een fijne feature, want bij MySQL is dit helaas niet mogelijk.

Helaas zijn er ook nadelen met de overstap naar PostgreSQL zoals dat voor MediaWiki 1.15 een nieuwe versie van PostgreSQL vereist is. Ik gebruik nu 8.1 en dan zal 8.3 nodig zijn volgens de specificaties. Een tweede punt en dat hangt samen met deze aanpassing is het laden van tsearch2-ondersteuning, maar deze ondersteuning zou bij PostgreSQL 8.3 standaard is de database moeten zitten. Voorlopig voldoet Mediawiki 1.14 en kan de upgrade nog even wachten tot het moment dat de databaseserver overgaat van Debian 4.0 naar Debian 5.0 deze zomer.

Nu deze migratie van MySQL naar PostgreSQL gedaan is gaat wordt het tijd om de volgende migratie te gaan voorbereiden. Dit zullen hoogstwaarschijnlijk Dovecot en Postfix gaan worden, maar eerst even kijken of er nog issues uit de migratie van MediaWiki komen.