1
2
3
4
5

curr = conn.cursor()
try:
    curr.execute("""delete from tabel where x > 2""")
except Exception, e:
    exit(1)

Het antwoord was helaas snel gevonden en deed me terug denken aan de eerste stappen op Oracle. Een dikke 15 jaar geleden, dat wel. De bijgewerkte code hieronder vertelt eigenlijk wel het verhaal.

1
2
3
4
5
6
7

curr = conn.cursor()
try:
    curr.execute("""delete from tabel where x > 2""")
    conn.commit()
except Exception, e:
    conn.rollback()
    exit(1)

Ik heb me laten misleiden door de autocommit bij andere modules binnen PHP en Perl als een eerstejaars. Want daar stopt autocommit op het moment dat je een transactie start, maar hier moet alles worden gecommit. Dit doet met denken of er dirty read/write bugs zijn te vinden in sommige applicaties die autocommit doen.

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.

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.

De voorwaarde voor een goede werking is om goede statistieken te hebben om zo een kansberekening te maken. En hoewel er discussie bestaat over hoe deze statistieken moeten worden gemaakt lijkt de methode nu te werken om het filter op een regelmatige basis zowel spam- als hamberichten te voeden. Hoe je aan deze berichten komt laat ik nu even buiten beschouwing. De eerste stap op Bayesian-filtering aan te zetten in SpamAssassin is door de volgende aanpassingen te maken in /etc/spamassassin/local.cf:

use_bayes 1
bayes_auto_learn 0

Na deze aanpassing moet een database worden aangemaakt in PostgreSQL en moet worden voorzien van de tabellen die in /usr/share/doc/spamassassin/sql/bayes_pg.sql staan. Hierna moet /etc/spamassassin/local.cf worden uitgebreid met de onderstaande regels om SpamAssassin de database te laten gebruiken.

bayes_store_module Mail::SpamAssassin::BayesStore::PgSQL
bayes_sql_dsn dbi:Pg:dbname=database;host=localhost;port=5432
bayes_sql_username gebruiker
bayes_sql_password wachtwoord

Vanaf dit moment kan SpamAssassin gebruik maken van PostgreSQL om te beoordelen en met spamassassin –lint kan worden gecontroleerd of alles correct werkt.

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.