PostgreSQL en NULL

Mijn docenten zullen wel de koude rillingen krijgen, maar soms heb je gewoon attribuut op je tupel staan die de geen waarde heeft. NULL is hier de algemene benaming voor zoals C-programmeurs die ook wel kennen. De grap komt hoe je tupels gaat selecteren die geen waarde hebben. Veel mensen zie je het volgende statement gebruiken en daarna zoeken waarom hun code fout loopt.

# SELECT * FROM TABLE WHERE column1 = NULL;

Het correcte statement hiervoor staat hieronder en de truuk zit hem in de IS. Je wilt geen vergelijking van de waarde van het attribuut, maar je wilt iets weten over de staat van het attribuut.

# SELECT * FROM TABLE WHERE column1 IS NULL;
# SELECT * FROM TABLE WHERE column1 IS NOT NULL;

De tweede regel is een klein toegift om te kijken of het attribuut niet NULL vertegenwoordigd. Zal de komende periode kijken of ik nog meer van dit soort leuke PostgreSQL dingetjes kan posten.

AWL vervuiling opschonen

SpamAssassin heeft de optie om te leren en te scoren op basis van een combinatie van e-mail en IP-adres. Nu lijkt deze optie zinvol en het lijkt te werken, maar hoever het schaalt is nog de vraag. Wat het schalen gaat beïnvloeden is de hoeveelheid combinaties die in de database staan en hoe snel deze combinaties te doorzoeken zijn. Helaas is er geen standaardoplossing in SpamAssassin om de AWL-tabel op te schonen, maar gelukkig zijn er opties binnen PostgreSQL om dit te regelen.

De eerste stap is om de AWL-tabel aan te passen door een attribuut toe te voegen met het volgende SQL-commando:

alter table awl add lastupdate timestamp with time zone default now();

De tweede stap is om een trigger te definiëren en aan de tabel te koppelen met het volgende SQL-commando:

CREATE OR REPLACE FUNCTION trg_handle_awl_lastupdate() RETURNS TRIGGER AS $BODY$
BEGIN
IF NEW.lastupdate = OLD.lastupdate THEN NEW.lastupdate := now(); END IF;
RETURN NEW;
END;
$BODY$ LANGUAGE 'plpgsql';
CREATE TRIGGER trg_handle_timestamp BEFORE UPDATE ON awl FOR EACH ROW EXECUTE PROCEDURE trg_handle_awl_lastupdate();

Vanaf dit moment zal het attribuut lastupdate elke keer worden bijgewerkt wanneer de combinatie door SpamAssassin wordt gezien en daardoor ook de tabel bijwerkt. Door nu wekelijks of dagelijks een SQL-script te draaien die bijvoorbeeld elke combinatie die te lang onaangeraakt is te verwijderen. Zoals de voorbeeld code hieronder.

delete from awl
where ( lastupdate < = now() - interval '4 months' and count > 1 )
or ( lastupdate < = now() - interval '3 months' and count = 1 );

Belangrijk om mee te nemen dat het soms even kan duren voordat bepaalde combinaties weer worden gezien. Veel mailinglisten komen meestal wel eens per maand voor. De interval van 3 maanden zou deze lijsten dus voldoende tijd moeten geven om een score te vormen.

MySQL redden of migreren???

MySQL logoEen 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 is not a standard?

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.

MySQLism slaat weer toe

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.