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

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.

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.

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.

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.

Door het plaatsen van de optie default-storage-engine in my.conf zoals hieronder dan zullen nieuwe tabellen standaard worden aangemaakt met de InnoDB storage-engine ipv MyISAM.

[mysqld]
default-storage-engine=InnoDB


Bestaande tabellen worden niet geraakt door de aanpassing my.conf, maar met het volgende SQL-statement het is mogelijk om een tabel om te zetten naar InnoDB.

alter table <name> engine=InnoDB;


Het is nu alleen nog wachten op de Falcon-engine zodat MySQL in de buurt komt van PostgreSQL zodat taken zoals een database-engine voor SpamAssassin een goede optie wordt bij veel transacties.

Maar het was al even mogelijk om PostgreSQL als database voor MediaWiki te gebruiken, maar er waren nog voldoende onvolkomenheden. Gelukkig komt daar met versie 1.10.1 verandering is en worden zoekfuncties betrouwbaar naast de al goede performance van MediaWiki op PostgreSQL die zeker te vergelijken is met de MySQL implementatie.

Hopelijk maken meer projecten zich sterk om PostgreSQL als database backend te gaan gebruiken, want concurrentie cq competitie is goed in de open source wereld om een gezonde omgeving voor iedereen te maken en te houden.