On 2015-12-22 20:04, Luis Falcon wrote: > On Tue, 22 Dec 2015 18:54:27 +0100 > Cédric Krier <[email protected]> wrote: > > On 2015-12-22 17:29, Luis Falcon wrote: > > > On Tue, 22 Dec 2015 12:33:00 +0100 > > > Cédric Krier <[email protected]> wrote: > > > > > > > Hi, > > > > > > > > I'm trying to make the tests working back on GNU Heath, so I work > > > > module per module. So far, I have done almost half of them. > > > > But now I have to come back to the first module 'health' because > > > > of changeset 8665a21223e2 because the SQL query doesn't work on > > > > SQLite. (It is important to use python-sql to write portable SQL > > > > queries). > > > Agree. We're going on that direction, and most code has been moved > > > to python-sql, but for upgrades "run-once" snippets I've been using > > > standard SQL code, that could be used also directly from the psql > > > interpreter. > > > > But it was not standard SQL code as it doesn't run on SQLite. > I look at it the other way around. SQLite uses Postgres as their > reference platform ("What Would Postgres Do")
An implementation is not a standard. > > The main issue was the usage of TRUE which is not in the SQL standard. > Don't agree. The "IS TRUE" predicate is part of the SQL standard (F571 > ext), that has been around for quite a while. PostgreSQL is one of the > systems that conforms to this SQL standard. Indeed but F571 is supported by very few databases [1]. That's exactly why we should never write raw SQL but python-sql because with this abstraction we can generate valid SQL for any database. > Moreover, IMHO, PostgreSQL is one of the most SQL conformant DBs, and > we should follow it. I think it is wrong if we can not run test on SQLite because the raw SQL query is not supported. More over, PostgreSQL has some non-standard behaviour nor non-standard function. I don't see the point to stick to one database when we have the tool to support others. More over which PostgreSQL version should be the standard in this case? > > I think the option to copy/paste the query in psql is not so much > > important against the portability. > Arguable. As we discussed a while ago, probably the best thing to do > in the future is to run sql scripts for code to be "run-once" in > upgrades. That would result in cleaner __register__ (s) Tryton has a clean and reliable way to manage upgrade that works since 7 years. I don't see the point to not use it. > > Also someone who is able to find this query in the code will be able > > to convert it from python-sql to plain SQL. > True. But still would have to do the job of conversion. For his database which has we have seen is not trivial. Also it is still possible to ask python-sql to generate the query. Any way, for me we should consider as a bug that must be fixed if the test doesn't work on any database supported by Tryton. [1] https://en.wikipedia.org/wiki/Null_%28SQL%29#Null-specific_and_3VL-specific_comparison_predicates -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpyrRqLuMVR3.pgp
Description: PGP signature
