Thu, 18 Feb 2016 14:22:07 +0100 [autoform] Avoid two calls to field.process_form for the same field in some cases
Sylvain Thénault <sylvain.thenault@logilab.fr> [Thu, 18 Feb 2016 14:22:07 +0100] rev 11897
[autoform] Avoid two calls to field.process_form for the same field in some cases when some entity is being created and data include non-inlined relations, the values for this relation are now stored for later usage, avoiding two calls to field's process_form method, which may be unexpected for custom fields. This has been discovered in saem_ref#f5444b1f9770. Reorganize imports in the test along the way.
Mon, 19 Dec 2016 17:22:48 +0100 [pyramid] Don't use unsafe_cnx_context_manager for write queries 3.24
Sylvain Thénault <sylvain.thenault@logilab.fr> [Mon, 19 Dec 2016 17:22:48 +0100] rev 11896
[pyramid] Don't use unsafe_cnx_context_manager for write queries we may have clumsy error that hide previous problems on attempting to commit the transaction. Closes #16753531
Wed, 14 Dec 2016 08:37:11 +0100 Repair database wrt indexes / unique constraints 3.24
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 14 Dec 2016 08:37:11 +0100] rev 11895
Repair database wrt indexes / unique constraints * recreate indexes dropped by 3.23 migration (but it's still unclear why) * attempt drop remaining extra indexes (there may be a bunch of these on old instances) * warn about missing expected indexes Closes #16666137
Wed, 14 Dec 2016 17:06:24 +0100 Enhance postgres index filter with values from real life 3.24
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 14 Dec 2016 17:06:24 +0100] rev 11894
Enhance postgres index filter with values from real life This has been found on fairly old instances of ours (cwo/elo). Dunno if we really want this in, it may lead to false negatives.
Wed, 14 Dec 2016 17:04:29 +0100 Extract functions to list expected/found database indexes from check_indexes 3.24
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 14 Dec 2016 17:04:29 +0100] rev 11893
Extract functions to list expected/found database indexes from check_indexes so they may be used from other contexts. Use consistent naming along the way: always use indexes, not indices.
Thu, 24 Nov 2016 15:36:26 +0100 Simplify and fix _cw.drop_entity_cache
Sylvain Thénault <sylvain.thenault@logilab.fr> [Thu, 24 Nov 2016 15:36:26 +0100] rev 11892
Simplify and fix _cw.drop_entity_cache * it's never called with an eid as argument, beside in a useless case in test (removed) * the only place where it's called from outside the tests is in full-text reindexation in server.checkintegrity: we could removed the request implementation and move it in unittest_rset, byt I decided to keep it for consistency with all other entity cache handling methods * get back a fix from Julien Cristau for the connection's implementation, quoting is commit message: When removing an entity from the transaction's cache, clear the entity's own cache May avoid issues where an entity object is still accessible somewhere else (e.g. an operation) after dropping it from the transaction's cache, with a stale attribute or relation cache.
Fri, 18 Nov 2016 17:50:56 +0100 [entity/optimization] Cache rset when entity.related is called with entities=False
Sylvain Thénault <sylvain.thenault@logilab.fr> [Fri, 18 Nov 2016 17:50:56 +0100] rev 11891
[entity/optimization] Cache rset when entity.related is called with entities=False If fail to see why we couldn't cache in this case, while this is important for optimization reason: when doing a single HTTP request, some queries are done two or three times because of predicates / uicfg or alike. Also always store tuple and not list in the cache, because: * else we get some regression * and inconsistent result type (tuple or list) * and it simply feels better to cache an unmutable object.
Wed, 14 Dec 2016 08:47:06 +0100 Ensure in 3.24 migration that entities from LDAP have consistent cwuri 3.24
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 14 Dec 2016 08:47:06 +0100] rev 11890
Ensure in 3.24 migration that entities from LDAP have consistent cwuri Closes #16666157
Wed, 14 Dec 2016 13:34:08 +0100 [doc/book] fix error in markup 3.24
Nicolas Chauvat <nicolas.chauvat@logilab.fr> [Wed, 14 Dec 2016 13:34:08 +0100] rev 11889
[doc/book] fix error in markup
Wed, 09 Nov 2016 16:14:17 +0100 [rtags] Allow to 'derive' rtags
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 09 Nov 2016 16:14:17 +0100] rev 11888
[rtags] Allow to 'derive' rtags Since some releases, rtags (structure underlying uicfg) have selector and may be copied using something like: new_rtags = deepcopy(original_rtags) new_rtags.__module__ = __name__ new_rtags.__select__ = custom_selector The problem is that starting from that, both rtags wil diverge and changes in original_rtags won't be considered, while we usually want to set a few specific rules only in new_rtags. To fix this problem, this cset introduces the notion of "derivated/parent" rtag, eg: new_rtags = original_rtags.derive(__name__, custom_selector) Beside easier copying, when using the above method changes in original_rtags which are not overriden by new_rtags will be considered since it only hold its specific rules but look among its parent chain for non-found keys. Along the way, flake8 unittest_rtags. Closes #16164880
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip