Mon, 19 Jun 2017 18:00:26 +0200 [web] Only log exceptions in debug mode in Ajax controllers
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 19 Jun 2017 18:00:26 +0200] rev 12187
[web] Only log exceptions in debug mode in Ajax controllers When we raise a RemoteCallFailed error (erroneously turned into a '500 Internal Server Error' response, but that's another business). In production environment, we do not want to log the exception in most cases where it's actually a client error. So only log the exception in debug mode.
Tue, 06 Jun 2017 12:20:17 +0200 [pyramid] Only expose 'cubicweb.bwcompat' setting for "all-in-one" configuration type 3.25
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 06 Jun 2017 12:20:17 +0200] rev 12186
[pyramid] Only expose 'cubicweb.bwcompat' setting for "all-in-one" configuration type The "pyramid" instance configuration does not work with "cubiwceb.bwcompat" mode (on purpose). Yet, having the setting exposed in development.ini file (generate by `cubicweb-ctl create --config pyramid <cube> <instance>` command) is misleading and we want to remove it. Thus, we only query this setting when cubicweb configuration is "all-in-one" and drop the setting line from templated development.ini file. If the option is found and True for any other configuration type, we issue a user warning (and ignore the option).
Thu, 27 Apr 2017 10:16:39 +0200 [migration] Only drop moved table entities if it does not exists 3.25
Yann Voté <yann.vote@logilab.fr> [Thu, 27 Apr 2017 10:16:39 +0200] rev 12185
[migration] Only drop moved table entities if it does not exists For very old instances (namely docaster), this table has never been created.
Fri, 05 May 2017 17:57:10 +0200 [web/views] delete: show composite entities in predictible order 3.25
Philippe Pepiot <philippe.pepiot@logilab.fr> [Fri, 05 May 2017 17:57:10 +0200] rev 12184
[web/views] delete: show composite entities in predictible order Iterate over relations type in alphabetical order, so the order is predictible dans does not depend on PYTHONHASHSEED.
Fri, 28 Apr 2017 09:49:37 +0200 [req] fix find() generating non-rewritable rql on non final relations
Philippe Pepiot <philippe.pepiot@logilab.fr> [Fri, 28 Apr 2017 09:49:37 +0200] rev 12183
[req] fix find() generating non-rewritable rql on non final relations When filtering on a relation, find() was generating rql like 'Any X WHERE X is ETYPE, X relation EID' which work without being rewritten (it should probably not), but when applying some rewrite (eg. permissions) it raise in rqlrewrite code. def _use_orig_term(self, snippet_varname, term): ... > self.rewritten[key] = term.name E AttributeError: 'Constant' object has no attribute 'name' Generate valid rql instead 'Any X WHERE X is ETYPE, X relation Y, Y eid EID'.
Wed, 26 Apr 2017 15:04:40 +0200 [req] raise KeyError instead of AssertionError in req.find()
Philippe Pepiot <philippe.pepiot@logilab.fr> [Wed, 26 Apr 2017 15:04:40 +0200] rev 12182
[req] raise KeyError instead of AssertionError in req.find()
Tue, 25 Apr 2017 17:31:24 +0200 [req] use format() instead of % substitution
Philippe Pepiot <philippe.pepiot@logilab.fr> [Tue, 25 Apr 2017 17:31:24 +0200] rev 12181
[req] use format() instead of % substitution For readability, avoid escaping using %% and use format() instead.
Tue, 25 Apr 2017 17:11:18 +0200 [test] make assertions on exception message
Philippe Pepiot <philippe.pepiot@logilab.fr> [Tue, 25 Apr 2017 17:11:18 +0200] rev 12180
[test] make assertions on exception message
Tue, 25 Apr 2017 17:10:16 +0200 [req] clearer exception message
Philippe Pepiot <philippe.pepiot@logilab.fr> [Tue, 25 Apr 2017 17:10:16 +0200] rev 12179
[req] clearer exception message Display what attribute trigger the NotImplementedError
Fri, 21 Apr 2017 10:29:44 +0200 [cleanup] Drop useless fake function
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.
Fri, 21 Apr 2017 10:29:07 +0200 [cleanup] Use plain unittest main in unittest_rqlrewrite
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
Tue, 25 Apr 2017 17:35:29 +0200 [cleanup] Fix flake8 error 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!
Thu, 20 Apr 2017 18:05:06 +0200 [rqlrewrite] Enhance detection of need for Exists node
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
Fri, 21 Apr 2017 09:57:04 +0200 [rqlrewrite] Fix rewrite on ambiguities introduced by NOT relation or "is IN" type restriction
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
Wed, 19 Apr 2017 09:05:10 +0200 [dataimport] Add explanation about why external entities can't be inserted
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.
(0) -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 tip