https://bugs.freedesktop.org/show_bug.cgi?id=51781
--- Comment #9 from Lionel Elie Mamane <lio...@mamane.lu> --- (In reply to comment #8) > As one of the reasons for ruling out SQLite was its dynamic typing I want to > point out that SQLite actually supports type constraints: > http://www.sqlite.org/lang_createtable.html#ckconst > So by adding CHECK() constraints one actually can ensure that columns only > contain data that matches the declared type. It is out of the question to require users to add check constraints manually. As to adding them automatically, it would be a significant deviation of the behaviour "with SQLite" (add the CHECK clauses) and "with another datasource" (don't add the CHECK clauses); the least we have to special-case, the better. Especially since this "add CHECK clauses" would be rather difficult to do at the driver level (rather than adding SQLite-specific hacks to the part of LibO that is supposed to be datasource-agnostic, and which constructs SQL statements to be executed); the driver gets an SQL string, so if it wants to fiddle with it, then it has to parse it. If we can use SQLite's parser (can we? is there an API call to get a parse tree from an SQL string?), then maybe OK. Or using LibO's parser... after all it wouldn't be so bad that the embedded DB can only do what LibO's parser can understand. Another thing I dislike about SQLite is that it does not support RIGHT JOIN, as per http://www.sqlite.org/syntaxdiagrams.html#join-op . That's often theoretically not a problem (just switch the arguments and do a LEFT JOIN), but again that's a "fixup of SQL string to comply to SQLite restrictions" we'd have to do. The more of these things we have to do, the more fragile the whole edifice becomes. Also, it conflicts with the fix for bug 42165. Yes, SQLite supports nested/bracketed joins, so we can theoretically not force left-recursion when connecting to SQLite, but *again* a thing we need to do different for SQLite than for all other datasources. > The other reason I find in bug 36824 were the embarrassing stunts apparently > needed for date-time operations. One would work arround the demonstrated > issues by assigning a date-time aware collation to date-time columns: > http://www.sqlite.org/datatype3.html#collation The documentation does not speak of datetime collation, so you mean we have to write it ourselves? You are just making the point that SQLite is a "storage engine" that one can possibly BUILD UPON to make an ISO SQL database, but it is not there. I don't think that a datetime collation will fix all the issues, for example of non-comparison operators doing the right thing. What about: CREATE TEMPORARY TABLE tst (num INTEGER NOT NULL, d DATE, PRIMARY KEY ("num")); INSERT INTO tst VALUES (1, '1970-03-01'); INSERT INTO tst VALUES (2, '1970-03-31'); SELECT num, d+1 AS dp1 FROM tst; This should give: 1 | 1970-03-02 2 | 1970-04-01 Will it? Don't think so. Right now (so without the putative datetime collation) it gives: 1 | 1971 2 | 1971 -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
