Am Rande notiert ...

wiki.dbpedia.org : About. Auch interessant – hier wird die Wikipedia durchforstet und nach strukturierten Informationen ausgewertet. Also sozusagen aus der Wikipedia für Menschen eine Wikipedia für Maschinen gemacht. Dem ganzen vorgepackt ist dann eine Abfragesprache und ein passender Webservice.

GT.M. Und weil ich dabei bin, hier gleich die dritte open source Mumps Implementierung. Die hier war mal kommerziell und ist dann in 2000 frei geworden. Hat also einiges auf dem Puckel an Jahren und ist nicht so ein Bastelprojekt von irgendwelchen Enthusiasten, sondern wird durchaus kommerziell weiterbetrieben (z.B. für Lizenzen auf anderen Systemen als Linux und OpenVMS). Wenn man sich so die Beschreibung durchliest, dann haben sie gleich mit der ganzen Sammlung von Buzzwords nach dem Tool geworfen. Ok, bei einer Sprache die ihre Datenbank einfach als globale Variablen in die Programme mapped ist STM ja sozusagen schon eingebaut. Auch wenn das vielleicht etwas gemogelt ist.

mumps. Ja, noch eine Implementierung, die scheint sogar einiges der altertümlichen Jobcontrols und anderer obskurer Artefakte zu implementieren. Naja, seit NoSQL wird wahrscheinlich auch Mumps wieder hoffähig. Die hier muss man allerdings selber kompilieren, da sind keine Binaries direkt für OSX verfügbar.

Mumps/II MultiDimensional and Hierarchical Toolkit. Ja, ich bin mal wieder in Sachen absurder Programmiersprachen unterwegs und hab hier ein Mumps aufgestöbert, das open source ist und unter verschiedenen Systemen läuft. Keine Ahnung was ich damit machen werde, aber irgendwas schmerzhaftes wird es sein müssen.

storm-gen – Lightweight DAO generator for Android SQLite – Google Project Hosting. Hmm, könnte ich mir mal angucken, ein weiterer ORM für SQLite unter Android.

The SQLite RTree Module. Und noch eine Erweiterung für SQLite, diese hier eine Standarderweiterung. R-Trees sind Baumstrukturen die optimiert sind für Range-Abfragen – also Wertebereichabfragen wie z.B. „ist dieses gegebene Rechteck in der Liste der Rechtecke enthalten“.

The Gaia-SINS federated project home-page. Nur schnell markiert, falls ich es mal brauchen könnte – spatiale Daten (GIS-Daten) in SQLite mit einer Erweiterung effizient indizieren und abfragen können. Da ich erklärter Fan von SQLite bin, durchaus interessant. Und es ist als dynamisch ladbare Erweiterung realisiert (tuts natürlich nur wenn das SQLite das man benutzt auch für Erweiterungen freigeschaltet ist – leider oft nicht der Fall, Installation könnte also eigene Neukompilation von SQLite erfordern, aber so schrecklich ist das nicht).

ActiveAndroid | Active record style SQLite persistence for Android. Hmm, mal angucken – ein weiterer ORM für Android, aber einer mit recht interessanter Syntax. Der Source verspricht auch noch ein paar mehr Sachen wie z.B. Joins. Wenn dann auch noch Migrations brauchbar abgebildet werden (daran krankt es erschreckend oft), könnte mich das Projekt durchaus motivieren mal mein kleines Bastelprojekt umzustellen.

couchbase/Android-Couchbase. Als Alternative zu SQLite unter Umständen interessant – vor allem, wenn man weniger mit strukturierten Daten sondern mehr mit Dokumenten arbeitet. Denn CouchDB bietet da echte Vorteile. Zusätzlich bekommt man damit eine Sync-Infrastruktur zur automatischen Replikation von Datenbankänderungen auf einen zentralen Server. Und zwar ohne wie bei SQLite Lösungen dafür Textexporte mit Dropbox-Sync zu bauen. Wobei letzteres erstaunlich gut funktioniert in den Situationen in denen ich das brauche.

Postgres-XC project Page. Multi-Master (Read und Write) Cluster für PostgreSQL. Unterstützt replicated Setups genauso wie partitioned Setups (oder Mischformen).

mitmel/SimpleContentProvider. Sieht aus wie ein einfacher ORM der automatisch einen Android Content Provider generiert. Dadurch wird das Erstellen deutlich schlanker im Code.

OrmLite – Lightweight Object Relational Mapping ORM Java Package. Mal genauer angucken, ein ORM der auch in Android benutzbar ist. Die nackte Programmierung von SQLite mit SQLiteDatabaseHelper macht mir irgendwie nicht so richtig viel Spaß. Das ist mir dann doch etwas zu low-level.

SQLite4: The Design Of SQLite4. Das klingt sehr interessant. Besonders der erste Absatz in „2.0 Overview“, in dem er ein wenig darauf rumreitet, dass SQLite3 weiter unterstützt wird und beide Versionen parallel verfügbar bleiben. Und natürlich dann die diversen Änderungen, die SQLite4 gegenüber der anderen Version haben wird, wie zum Beispiel die deutlich bessere Kapselung der Engine in einem eigenen Objekt. Dadurch ist es durchaus möglich mehrere Datenbanken gleichzeitig offen zu haben, ohne großes jonglieren. Und was mich besonders freut: alle Berechnungen in Decimal Math und nicht mehr double oder float. Sorry, aber double (und schon gar nicht float) hat irgendwas in einer Datenbank zu suchen, ausser vielleicht als Datentyp für seltene Sonderfälle. Auch sonst einige nette Sachen drin, zum Beispiel covering indexes und natürlich die standardmäßig verfügbaren foreign key constraints.

Make runfcgi fail when database connection is open before fork. Das ist eine Sache nach der ich schon ewige Zeiten jage, zuletzt in ein paar ziemlich wichtigen Projekten. Flup arbeitet so, dass es die WSGI-Anwendung erst initialisiert und mit dieser initialisierten WSGI Anwendung dann die Forks für die Worker macht. Dummerweise gibt es bei uns aber Datenbankzugriffe wärend der Anwendungsinitialisierung – dadurch hat der Basisprozess schon eine offene Datenbankverbindung, jeder Fork kopiert diese Daten. Aber der Socket der Verbindung geht natürlich nicht mit – der neue Prozess denkt nur er wäre verbunden, ist es aber nicht. Zugriffe von denen neuen Prozessen fallen dann mit einer Exception raus. Man kann im verlinkten Patch auch gut den raise auf die Exception einfach durch connection.connection = None ersetzen. Dann wird einfach die Verbindung die sowieso defekt ist weggeworfen und in neuen Prozessen immer eine neue Verbindung aufgebaut. Damit haben wir zumindestens in einem Produktionsumfeld (mit psycopg2) das ganze beheben können und sind guten Mutes, dass es auch bei der Umgebung  mit pyodbc helfen wird.

SET TRANSACTION ISOLATION LEVEL Transact-SQL. Da gibts mehr Infos zum Isolation-Level in MSSQL, speziell was die Snapshot-Geschichte bedeutet. Im Prinzip bringt man MSSQL damit dazu sich ähnlich zu PostgreSQL zu verhalten.

Enabling Snapshot Isolation – SQLAlchemy 0.7 Documentation. Könnte uns das helfen? MSSQL hat scheinbar einen eher ungünstigen Isolation-Level als Default. Hmm, werden wir wohl mal ausprobieren.

r17 – flexible, scalable, relational data mining language. Sieht ganz interessant aus, im Prinzip sowas wie eine Kreuzung aus AWK und SQL. Das Ergebnis ist nicht wirklich schön, aber wirkt praktisch – speziell weil man auf einfache Weise mehrere Prozessoren nutzen kann, oder sogar mehrere Maschinen (implizite Parallelisierung), und damit auch recht einfach große Datenmengen mit ad-hoc Queries auswerten kann. Dadurch, dass es ein einfaches Format für die Übermittlung von daten an weitere Schritte gibt, kann man es auch leicht auf neue Datenquellen anpassen, ohne dort erst einen langwierigen Exportschritt laufen zu lassen.

The Schemaverse. Und weil wir gerade bei seltsamen Projekten sind: da hat jemand ein MMO programmiert, das komplett innerhalb PostgreSQL läuft. Also pgSQL als Sprache benutzt. Sowas wie ein Multi-User-Schiffeversenken. Nur läuft es halt in einer Datenbank. Und wird über SQL bedient.

RavenDB – 2nd generation document database. Geblogmarkt weil ich mir das mal in der nicht zu fernen Zukunft angucken will. Klingt von den Features her recht interessant und ist vielleicht für das eine oder andere Projekt, über das ich zur Zeit nachdenke, brauchbar.

TL Omnis. Und noch so ein RAD Oldtimer – Omnis war eine der ersten RAD Umgebungen mit der ich gespielt habe und sie war recht ungewöhnlich für die damalige Zeit. Keine „richtige“ Programmierung damals, nur GUI Tools zur Verdrahtung und Verbindung in Kombination mit berechneten Feldern, aber diese sehr leistungsfähig. Sehr starker Fokus auf grafische Werkzeuge für verschiedenste Zwecke (DB Design, Relationsmanagement, Reports, Formulare etc.). Schon erstaunlich was man alles findet, wenn man etwas nachbuddelt. Gibt übrigens eine freie Standardversion der Umgebung, man kann also einfach mal reingucken was es heute so alles kann.

Bulbflow: a New Python Framework for Graph Databases. Auch wenn ich immer wieder denke, Graphdatenbanken sind eigentlich sowas von 70er Jahre, nicht alles was alt ist ist automatisch schlecht – IMS ist ja auch immer noch da und für manche Zwecke sehr interessant. Und das hier klingt interessant, sowas wie DBAPI für Graphdatenbanken, so dass man in seinen Projekten auch mal die Datenbank wechseln kann, ohne das alles komplett umgeschrieben werden muss.

NOSQL Databases. Sehr gute Übersicht über alle möglichen verfügbaren NoSQL-Datenbanken. Guter Startpunkt wenn man sich über die verfügbaren Systeme und deren Ausrichtung und Implementierung infomieren will.