Zum wunderbaren Kommentar bzgl. meines letzten Blog-Eintrags - eigentlich erst als Kommentar gedacht, aber aufgrund der Länge und der IMHO interessanten Beispiel jetzt doch als eigenständiger Eintrag:
Danke für den Auszug des SQLite-Manuals. Aber ich bleib dabei, das ist "unvorteilhaft" und nicht das, was man erwarten kann.
Was für einen Vorteil hat es für mich als User/Programmierer von SQLite, wenn die DB nichtmal den Typen überprüft? Das ich nochmals alles nachprogrammieren darf? Juche! Beispiel gefällig?
sqlite> create table foo ( a datetime );
sqlite> insert into foo values ('2008-09-04');
sqlite> insert into foo values ('04.09.2008');
sqlite> select * from foo order by a;
04.09.2008
2008-09-04
Nein, sorry, das kann man mir nicht mehr als Feature verkaufen. Und ganz so typeless ist sie ja auch nicht... Beispiel?
sqlite> create table int1 ( feld integer );
sqlite> create table int2 ( feld varchar(10) );
sqlite> insert into int1 values ('104');
sqlite> insert into int1 values ('10');
sqlite> insert into int1 values ('4');
sqlite> insert into int2 values (104);
sqlite> insert into int2 values (10);
sqlite> insert into int2 values (4);
sqlite> select * from int1 order by feld;
4
10
104
sqlite> select * from int2 order by feld;
10
104
4
Hier wird also doch das Typenfeld der Definition bzgl. der Suche interpretiert.
Aber halt! Man kann ja den Typen auch weglassen! Was passiert dann?
sqlite> create table int3 ( feld );
sqlite> create table int4 ( feld );
sqlite> insert into int3 values ('104');
sqlite> insert into int3 values ('10');
sqlite> insert into int3 values ('4');
sqlite> insert into int4 values (104);
sqlite> insert into int4 values (10);
sqlite> insert into int4 values (4);
sqlite> select * from int3 order by feld;
10
104
4
sqlite> select * from int4 order by feld;
10
104
4
Der geneigte Bastler entnimmt, das SQLite offensichtlich alles als String behandelt, außer es könnte, unter Umständen, vielleicht, irgendwo, bei Westwind, zunehmenden Mond oder sonstigen nicht durchsehbaren Zuständen doch irgendwo eine Typendefinition finden.
Mein Schluss: Zum Entwickeln auf dem Laptop ja. Produktiv? Never! :-(
Trackback URL for this post:
http://www.velt.de/trackback/106
Lies doch mal die
Lies doch mal die Datentypen-Dokuseite für Version 3 (der Auszug vom letzten Mal war für Version 2 (hatte wohl vergessen, Name und Mail anzugeben)). Abschnitt 6 könnte da helfen... allerdings finde ich Abschnitt 2.1 zum Brüllen, denn: Was passiert wenn ich etwas als "doubintext" definiere? :-D
SQLite-Bug #0815: "SQLite lacks proper date and time support"
Ach Du bist das! Sag das doch ,-)
OK, also, gut, das Verhalten ist wenigstens dokumentiert. Allerdings wird ein Bug kein Feature, wenn man es dokumentiert...
Für Zahlen und Texte mag das vielleicht ja noch irgendwo Sinn machen, aber beim Datum (man erinnere sich an mein ursprüngliches Problem...) ist das ein Bug. Wer dagegen argumentieren möchte, für den hab ich auch noch was: Windows ist praktisch fehlerfrei, schließlich ist praktisch alles in der "Knowledge Base" dokumentiert.
Was mich an der Sache aber so richtig wundert, ist die Tatsache, dass inzwischen viele SQLite als "die bessere Alternative zu MySQL" hinstellen. Und das kann's ja offensichtlich nicht sein.
Hans, danke für den Wink mit der Doku! Für mich bleibt's trotzdem ein Bug ;-)
re
Ich würde das eher "broken by design" nennen ;-)
Übrigens, danke für deine Blog-Einträge... ich schiebe schon ewig vor mir her, mir "endlich" mal SQLite anzusehen um es evtl. einzusetzen... das hat sich jetzt erübrigt ;-)
Btw: Ich wollte mit dem Doku-Auszug lediglich darauf hinweisen, dass die den Wahnsinn auch noch freiwillig zugeben, war nur zu faul was dazuzuschreiben :)
Kommentar hinzufügen