Thu, 21 Mar 2013 18:13:31 +0100 3.15 is the new old stable oldstable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 21 Mar 2013 18:13:31 +0100] rev 8746
3.15 is the new old stable
Mon, 17 Sep 2012 14:39:29 +0200 [web] don't link to None in author box (when author has been deleted) (closes #2409855) stable
Arthur Lutz <arthur.lutz@logilab.fr> [Mon, 17 Sep 2012 14:39:29 +0200] rev 8745
[web] don't link to None in author box (when author has been deleted) (closes #2409855)
Tue, 19 Mar 2013 18:20:57 +0100 dbapi: try to restore compatibility of the connect api with 3.15 stable
Julien Cristau <julien.cristau@logilab.fr> [Tue, 19 Mar 2013 18:20:57 +0100] rev 8744
dbapi: try to restore compatibility of the connect api with 3.15 A few issues here: - urlparse('foo').scheme is '', not None - cnxprops is an optional argument Regression from 62213a34726e ("[db-api/configuration] simplify db-api and configuration so that all the connection information is in the repository url, closes #2521848") Closes #2754322
Wed, 20 Mar 2013 17:40:25 +0100 3.16 is the new stable stable
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 20 Mar 2013 17:40:25 +0100] rev 8743
3.16 is the new stable After discussion with David Douard I'm merging 3.16.x branches in stable and starting 3.17 feature on default.
Tue, 19 Mar 2013 16:56:46 +0100 Added tag cubicweb-debian-version-3.15.10-1 for changeset feca12e4a618 stable
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 16:56:46 +0100] rev 8742
Added tag cubicweb-debian-version-3.15.10-1 for changeset feca12e4a618
Tue, 19 Mar 2013 16:56:45 +0100 Added tag cubicweb-version-3.15.10 for changeset 89bdb5444cd2 stable cubicweb-debian-version-3.15.10-1
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 16:56:45 +0100] rev 8741
Added tag cubicweb-version-3.15.10 for changeset 89bdb5444cd2
Tue, 19 Mar 2013 16:56:28 +0100 prepare 3.15.10 stable cubicweb-version-3.15.10
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 16:56:28 +0100] rev 8740
prepare 3.15.10
Tue, 19 Mar 2013 16:54:32 +0100 Added tag cubicweb-debian-version-3.16.1-1 for changeset 84fbcdc8021c
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 16:54:32 +0100] rev 8739
Added tag cubicweb-debian-version-3.16.1-1 for changeset 84fbcdc8021c
Tue, 19 Mar 2013 16:54:31 +0100 Added tag cubicweb-version-3.16.1 for changeset d95cbb7349f0 cubicweb-debian-version-3.16.1-1
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 16:54:31 +0100] rev 8738
Added tag cubicweb-version-3.16.1 for changeset d95cbb7349f0
Tue, 19 Mar 2013 16:53:57 +0100 prepare 3.16.1 cubicweb-version-3.16.1
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 16:53:57 +0100] rev 8737
prepare 3.16.1
Tue, 19 Mar 2013 15:30:06 +0100 [views/primary] some inner sections should use the `limit` by default to avoid a denial of service (closes #2719110)
Aurelien Campeas <aurelien.campeas@logilab.fr> [Tue, 19 Mar 2013 15:30:06 +0100] rev 8736
[views/primary] some inner sections should use the `limit` by default to avoid a denial of service (closes #2719110) Today, it is possible to call .related and get a huge unlimited database-dos-inducing resultset that will be nevertheless limited a bit further in pure python in the `autolimited` view. While we cannot completely avoid potential denial of services such as these we mitigate the problem with the default ui settings: if the inner vid is `autolimited`, then the relation result sets is computed using the user-defined limit. This change respects the semantics of the `autolimited` view and shouldn't break anything.
Tue, 19 Mar 2013 15:18:22 +0100 [entity] ensure the .related(entities=False) parameter is honored all the way down (closes #2755994)
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 ...
Tue, 19 Mar 2013 15:17:34 +0100 [test/web] fix invisibly bogus test (prepares #2755994)
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.
Fri, 08 Mar 2013 11:03:28 +0100 [cwconfig] Fix exception handling when building the cube dependency graph
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.
(0) -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 tip