menü

status

online seit 6454 tagen
letztes update am
28. November, 14:45

kalender

September 2005
Mo
Di
Mi
Do
Fr
Sa
So
 
 
 
 1 
 5 
 7 
10
12
13
15
23
25
28
30
 
 
 

aktuelles

Ich lebe noch!
nighthawk - 28.11. 14:45
Nach langer Zeit ...
nighthawk - 04.10. 23:09
Lösungen vom draufgucken
nighthawk - 27.02. 22:30
Mal 'was neues
nighthawk - 26.01. 22:29
Ganz Münster auf dem Aasee
nighthawk - 11.01. 20:17

historisches

suche

 

buttonmania

xml version of this page

paRSS - Feews! for the rest of us

startseite > Donnerstag, 22.09.2005


Donnerstag, 22. September 2005

Fliegende Stühle

"Google" ist das Wort, das angeblich Steve Ballmer auch dazu bringt, Stühle quer durch sein Büro zu werfen, wenn [...]
ich haette eigentlich erwartet, dass ballmer ein buero hat, in dem das nicht einfach so moeglich ist.. rein von den ausmassen her versteht sich.

SQLite mit Tcl und PHP


man stelle sich folgendes (natuerlich frei erfundenes, theoretisches) szenario vor:
ich habe ein script geschrieben, das tcl, php und mysql benutzt. nun besteht der bedarf das script in einer anderen umgebung zu nutzen und dort ist weit und breit als einzige datenbank (auf einem server mit kamikazemission) nur postgresql verfuegbar. ich portiere mein script also zu pgsql und in der form hat es die letzten (schaetzungsweise) zwei jahre auch zufriedenstellend gelaufen. nun ist der server mit der kamikazemission nicht mehr verfuegbar und ich dachte mir.. auf dem server, auf dem der tcl teil des scripts laeuft, willst du keine echte datenbank installieren (gross, schwerfaellig, aufwendig, usw..), auf den anderen servern laeuft das tcl script nicht. was kommt einem also in den sinn? genau.. alternativen: in diesem falle dachte ich spontan an sqlite.
also geguckt, ob ein tcl binding fuer sqlite verfuegbar ist - nein, der autor von sqlite behauptet sogar, dass tcl aeusserst gut mit sqlite zusammen funktioniert.. ich also sqlite (versionszweig 3.x) runtergeladen, installiert und munter mein script portiert. dabei stellte sich uebrigens heraus, dass sqlite tatsaechlich noch gravierende defizite gegenueber echten datenbanken hat.. man kann kein update geschachtelt in einem select auf der selben datenbank machen.. sowas empfinde ich doch als echten nachteil. aber gut, diese klippe umschifft und das script ans laufen gebracht, musste ich dann noch den php teil portieren.. also das sqlite paket fuer php installiert, die ersten teile in php umgeschrieben, im browser die seite geladen.. und es begruesst mich diese meldung:
Unable to open database "/var/mrtg/snmp.db": file is encrypted or is not a database
kurz recherchiert.. und fast vom glauben abgefallebn. php unterstuetzt nur sqlite in version 2. sqlite version 2 und 3 sind in ihrem datenbankdateiformat inkompatibel (sowohl abwaerts, als auch aufwaerts). ich also gedacht.. ok.. auf der downloadseite von sqlite haste ja auch den source fuer irgendeine version 2.x gesehen.. die also runtergeladen.. installiert.. und gewundert. es wurde kein tcl binding installiert, obwohl ich --with-tcl angegeben habe. nichtmal das modul fuer tcl wurde erstellt. sehr suspekt.. aber da ich so langsam (nach mehreren stunden arbeit) den kaffee auf hatte, habe ich mir einfach ein precompiled binary fuer linux runtergeladen, daraus ein tcl package gemacht und an die entsprechende stelle gelegt. natuerlich habe ich spontan eine funktion, die nur das sqlite 3 binding beherrscht, an mehreren stellen verwendet.. also nochmal 'ne stunde mein tcl script umgeschrieben. als das endlich fertig war, stand ich vor der lustigen frage, wie ich denn jetzt meine daten aus der sqlite3 datei raus bekomme.. auf die idee, dass man in der sqlite konsole mit .output die ausgabe in eine datei umleiten kann (muss) und dann sich mit .dump die struktur/daten ausgeben lassen kann, muss man auch erstmal kommen.. nachdem ich die daten da dann endlich raus hatte, schnell in eine neue sqlite2 db gepackt und mein script ausprobiert, das dann auch erstaundlicherweise lief.. also zurueck zum php teil. da kam dann wieder die lustige problematik der verschachtelung.. aber statt, wie tcl, eine fehlermeldung auszugeben, dass die datei gesperrt ist.. macht php ganz schlicht und ergreifend einen sementation fault. da weiss man dann naemlich auch genau, wo man suchen muss. einen ersatz fuer "now()" oder "CURRENT_TIMESTAMP" bietet sqlite uebrigens auch nicht oder zumindestens konnte ich keinen finden.. die eingabe von letzterem erzeugt zudem ebenfalls einen segmentation fault. nach zwei stunden rumraten im (eigentlich kurzen) php source habe ich das script aber dann doch schlussendlich ans laufen gebracht.
ich lerne fuer mich daraus: entweder direkt unter sqlite entwickeln, oder gleich ganz sein lassen. bei der spaeteren portierung stoesst man nur auf die defizite von sqlite. jetzt aber bitte nicht falsch verstehen: ich moechte nicht sqlite schlecht machen.. es erhebt ja ueberhaupt nicht den anspruch eine vollwertige datenbank mit allen funktionen zu sein.. aber es faellt eben doch auf, dass an manchen stellen noch was fehlt, wenn man von einer echten datenbank dahin portiert..
ältere beiträge