Sylvain Thénault <sylvain.thenault@logilab.fr> [Fri, 21 Apr 2017 10:29:44 +0200] rev 12178
[cleanup] Drop useless fake function
actually not necessary.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Fri, 21 Apr 2017 10:29:07 +0200] rev 12177
[cleanup] Use plain unittest main in unittest_rqlrewrite
Sylvain Thénault <sylvain.thenault@logilab.fr> [Tue, 25 Apr 2017 17:35:29 +0200] rev 12176
[cleanup] Fix flake8 error unittest_rqlrewrite
hard one!
Sylvain Thénault <sylvain.thenault@logilab.fr> [Thu, 20 Apr 2017 18:05:06 +0200] rev 12175
[rqlrewrite] Enhance detection of need for Exists node
We actually want one only if this is not a (`And` / `Or`) binary tree of `Not` or
`Exists` nodes, so write a recursive function to tell so.
Related to #17074119
Sylvain Thénault <sylvain.thenault@logilab.fr> [Fri, 21 Apr 2017 09:57:04 +0200] rev 12174
[rqlrewrite] Fix rewrite on ambiguities introduced by NOT relation or "is IN" type restriction
When some inserted RQL snippet generate more solutions than the original RQL,
the rewriter attempt to duplicate the snippet for each newly introduced
solution. There are though some cases where we do not want this behaviour in
case of ambiguities introduced by:
* NOT(X relation Y) expression, since it won't be
equivalent to NOT(X relation Y1, Y1 is Type1) OR NOT(X relation Y2, Y2 is
Type2) ;
* EXISTS(X relation Y, Y is IN (Type1, Type2) expression, since it's not
actually necessary to split an explicitly introduced ambiguity (and it crash
if we attempt to do so, so...).
In test, we've to modify the `rewrite()` function because in the newly
introduced test we need the same constraint to be applied to two variables in
the original query, and this was not supported before.
Notice the generated RQL in test is still *NOT CORRECT* "(EXISTS(NOT EXISTS() OR
EXISTS(...))", or at least isn't optimal. This will be fixed in a forthcoming
changeset.
Related to #17074119
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 19 Apr 2017 09:05:10 +0200] rev 12173
[dataimport] Add explanation about why external entities can't be inserted
By default after the import processed the importer indicates which external
entities can't be inserted because they are missing dependency data (other
entities, used in inlined or mandatory relations).
It usually helps there to find out which extids / relations are missing, so add
this to the log.
Philippe Pepiot <philippe.pepiot@logilab.fr> [Thu, 20 Apr 2017 17:22:36 +0200] rev 12172
[querier] Fix typo in Unauthorized message exception
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 19 Apr 2017 15:09:31 +0200] rev 12171
[massive store] Ensure temporary metadata table get dropped
even if there is some integrity errors while inserting entity values or setting
back index/constraints, or any other errors. In case of exception, rollback to
ensure we're not committing undesired intermediate state.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 19 Apr 2017 10:09:25 +0200] rev 12170
[test] Stop using lgc.testlib.unittest_main in dataimport's test_sqlgenstore.py
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 19 Apr 2017 10:08:59 +0200] rev 12169
[test/cleanup] Cleanup flake8 errors in dataimport's test_sqlgenstore
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 19 Apr 2017 10:18:47 +0200] rev 12168
[pkg] Fix path error in flake8-ok-files
'sources' is a subpackage of 'server'.
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 19 Apr 2017 15:16:10 +0200] rev 12167
[cleanup] Fix undetected pep8 error
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 19 Apr 2017 11:10:58 +0200] rev 12166
[doc] Set release date of 3.25 in changelog
Philippe Pepiot <philippe.pepiot@logilab.fr> [Fri, 14 Apr 2017 17:17:12 +0200] rev 12165
[cwconfig] load appobjects subpackages recursively
This is a regression appeared in 3.25.0. Appobjects (entities, views etc)
subpackages should be loaded recursively, this is the historical behavior,
relevant code is in logilab.common.registry._toload_info().
To keep historical behavior schema subpackages should not be loaded, relevant
code is in yams.reader.get_schema_files().
We may want to have a consistent behavior later on...
Closes #17073706.