Elexis läuft auf einer relationalen Datenbank. Eine solche Datenbank hat den Nachteil, dass Schemaänderungen relativ aufwändig sind. Insbesondere kann es schwierig sein, Ab- und Aufwärtskompatibilität sicherzustellen.
Um diesem Problem zu begegnen, und dem Anwender und Plugin-Programmierer zu ermöglichen, dynamische Felder, ähnlich einer NoSQL-Datenbank zu nutzen, wurden sogenannte ExtInfo-Felder eingeführt. Ein ExtInfo-Feld ist aus Sicht der Datenbank ein BLOB, aus Sicht der Anwendung eine Map
Als Persistenzformat für das ExtInfo-Feld wurde eine Java-Hashtable serialisiert und gezippt. Obwohl das Konzept von “lightweight”-Attributen für persistierte Objekte nach wie vor richtig ist, erwies sich diese Form der Implementation zunehmend als etwas unglückliche Wahl: Das Verwenden der ExtInfo Parameter blieb so auf Java-Anwendungen beschränkt, da die serialisierte Form der Hashtable hochgradig Java-spezifisch ist.
Es muss eine Lösung gefunden werden, welche die Kompatibilität zu existierenden Datenbanken und Elexis-Installationen nicht bricht, aber dennoch auch anderen Anwendungen (JavaScript, Access etc) den Zugriff ermöglicht.
Das ExtInfo Blob ist also im Grunde eine in ein Datenbankfeld gepackte ZIP-Datei. Sie enthält bisher lediglich einen Eintrag namens “hash”, welcher die serialisierte Hashtable enthält. Damit war der Ansatz einfach: Wir tragen eine zweite Datei in den ZIP-Blob ein. Diese ist, um möglichst breit les- und schreibbar zu sein, im universellen Format json gehalten, und wird unter dem Verzeichnisnamen “json” erstellt.
Als Resultat haben wir eine Zip Datei mit zwei Einträgen: “hash” und “json”, welche beide dieselben Daten in unterschiedlichem Format enthalten. Jetzt müssen wir nur noch dafür sorgen, dass jeder Schreibzugriff beide Einträge aktualisiert, und haben damit eine Lösung, die hundertprozentig kompatibel mit älteren Elexis-Installationen und Datenbanken ist. Folgende Akteure sind denkbar:
In einem ersten Schritt wird Elexis Ungrad ExtInfos doppelt schreiben, aber wie bisher das HashFormat bevorzugen. Fremdanwendungen (speziell Webelexis) können die json-Seite lesen, aber nicht schreiben (da sonst Desynchronisation droht)
Wenn sich dabei keine Probleme zeigen, wird Elexis Ungrad in einem zweiten Schritt die json Seite bevorzugen, und die hash-Seite nur noch aus Kompatibilitätsgründen mitführen.
Wenn auch das problemlos geht, wird in einem dritten Schritt das hash-Format nicht mehr weiter geführt.
Durch die doppelte Speicherung wird der benötigte Speicherplatz grösser. Allerdings ist es unwahrscheinlich, dass die Grenzen des BLOB Formats je erreicht werden.
Es werden leider nicht nur Name/Wert-Paare in Extinfos gespeichert, sondern auch Objekte anderer Klassen (zum Beispiel Kontakt#statL). Die Serialisierung/Deserialisierung solcher Objekte von und nach Json erfolgt via Jackson. Dabei kann es aber zu Problemen kommen, weil Jackson keine privaten Felder auslesen und wiederherstellen kann. bei Kontakt#statL wurden darum getter und setter zugefügt. Falls andere, bisher unbekannte Klassen andernorts ebenfalls in ExtInfo gespeichert wurden, kann der Serializer auf die Nase fallen.
Fremdanwendungen, die entgegen der Empfehlung Json schreiben, können die ExtInfo Felder desynchronisieren. der nächste Schreibzugriff von ElexisUngrad würde die Änderungen überschreiben.
Ein Mischbetrieb klassischer und moderner Elexis-Clients auf derselben datenbank ist möglich, sollte aber wegen der Gefahr, dass Json überschrieben wird, vermieden werden. Ein up/downgrade aller Stationen ist dagegen jederzeit unkritisch möglich. Es ist anzustreben, bald auf ein reines Json-Format zu wechseln.