Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 15:18:22 +0100] rev 8735
[entity] ensure the .related(entities=False) parameter is honored all the way down (closes #2755994)
As of today, such a call will always fill the relation cache by
calling .entities() on every single related rset entry.
As a consequence, the `limit` parameter handling also had to be fixed.
It was bogus in the following ways:
* not used in the related_rql, hence potentially huge database
requests, but also actually
* foolishly used in the .entities()-calling cache routine we now
bypass (this changeset ticket's main topic)
Now:
* we set a limit on the rql expression, and
* forbid caching if given a non-None limit (as we don't want to make
the cache handling code more complicated than it is already)
With this, entity.unrelated gets a better limit implementation (so the
code in related/unrelated is nice and symmetric)
Risk:
* _cw_relation_cache disappears completely, which is good, but this is
Python, so you never know ...
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 15:17:34 +0100] rev 8734
[test/web] fix invisibly bogus test (prepares #2755994)
The test was wrong but that was cancelled out by a cache effect and
fuzzy naming.
Wiping the entity caches restores sanity: the choices list are the
same before and after the SET.
Also field.choices uses entity.unrelated but always returns related +
unrelated elements.
Hence `choice` replaces `unrelated` where it makes sense.
AssertIn is used in place of AssertTrue.
Rémi Cardona <remi.cardona@logilab.fr> [Fri, 08 Mar 2013 11:03:28 +0100] rev 8733
[cwconfig] Fix exception handling when building the cube dependency graph
UnorderableGraph exceptions do not have a 'cycles' property. A simple
cast to str does the job.
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 12:25:18 +0100] rev 8732
[merge] backport stable fixes