health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] Testing


From: Chris
Subject: Re: [Health-dev] Testing
Date: Tue, 22 Dec 2015 16:24:38 -0800
User-agent: Mutt/1.5.24 (2015-08-30)

Hiya all!

On 12/22/15, Cédric Krier wrote:
> On 2015-12-22 20:04, Luis Falcon wrote:
> > On Tue, 22 Dec 2015 18:54:27 +0100
> > Cédric Krier <address@hidden> wrote:
> > > On 2015-12-22 17:29, Luis Falcon wrote:
> > > > On Tue, 22 Dec 2015 12:33:00 +0100
> > > > Cédric Krier <address@hidden> 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

I'm wondering if also we should look to code review tools. I know we
were talking about adding some sort of code review workflow. As a test
on my own server, I got a basic Kallithea installation up and running.
It has post-commit code review, etc.

It seems that after the new release we should try to address some of
these testing/CI/etc. issues in a robust way.

All the best,

-C



reply via email to

[Prev in Thread] Current Thread [Next in Thread]