Fri, 29 Jan 2016 17:11:17 +0100 [test] Add a test ensuring new cube built from skeleton is flake8-compliant
Denis Laxalde <denis.laxalde@logilab.fr> [Fri, 29 Jan 2016 17:11:17 +0100] rev 11176
[test] Add a test ensuring new cube built from skeleton is flake8-compliant And make skeleton files actually flake8-compliant henceforth.
Mon, 25 Jan 2016 08:28:16 +0100 [skeleton] Ship a tox.ini file upon new cube
Denis Laxalde <denis.laxalde@logilab.fr> [Mon, 25 Jan 2016 08:28:16 +0100] rev 11175
[skeleton] Ship a tox.ini file upon new cube
Thu, 10 Mar 2016 13:47:20 +0100 [web] fix headers on 304 responses (closes #11466875)
Julien Cristau <julien.cristau@logilab.fr> [Thu, 10 Mar 2016 13:47:20 +0100] rev 11174
[web] fix headers on 304 responses (closes #11466875) The response MUST include the following header fields: [...] - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 Unfortunately we weren't copying headers from what would have been the 200 response, but from the request.
Wed, 09 Mar 2016 18:01:44 +0100 [web/httpcache] GMTOFFSET no longer exists
Julien Cristau <julien.cristau@logilab.fr> [Wed, 09 Mar 2016 18:01:44 +0100] rev 11173
[web/httpcache] GMTOFFSET no longer exists
Thu, 10 Mar 2016 13:47:20 +0100 [web] fix headers on 304 responses (closes #11466875)
Julien Cristau <julien.cristau@logilab.fr> [Thu, 10 Mar 2016 13:47:20 +0100] rev 11172
[web] fix headers on 304 responses (closes #11466875) The response MUST include the following header fields: [...] - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 Unfortunately we weren't copying headers from what would have been the 200 response, but from the request.
Mon, 29 Feb 2016 12:32:52 +0100 [rset] fix infinite recursion introduced in c1eb5a676c80
Julien Cristau <julien.cristau@logilab.fr> [Mon, 29 Feb 2016 12:32:52 +0100] rev 11171
[rset] fix infinite recursion introduced in c1eb5a676c80 The mechanism to avoid loops in c1eb5a676c80 "[rset] Always complete attribute/relation caches in ResultSet.get_entity" breaks down: we would loop forever if two entities that were already in the cache were linked by a relation with ? or 1 cardinality in both directions. To avoid that, keep a set of already-considered columns. Related to #9942503.
Wed, 17 Feb 2016 10:02:03 +0100 pep8 unittest_application and unittest_formfields
Sylvain Thénault <sylvain.thenault@logilab.fr> [Wed, 17 Feb 2016 10:02:03 +0100] rev 11170
pep8 unittest_application and unittest_formfields
Tue, 12 Jan 2016 14:31:14 +0100 [rset] Always complete attribute/relation caches in ResultSet.get_entity
Alexandre Richardson <alexandre.richardson@logilab.fr> [Tue, 12 Jan 2016 14:31:14 +0100] rev 11169
[rset] Always complete attribute/relation caches in ResultSet.get_entity RQL queries are often designed to fill up the ORM's caches when fetching entities out of the result set. Until now, if an entry already existed in the entity cache, ResultSet.get_entity would return it unchanged, not using the new ResultSet's contents to update the attribute cache, breaking expectations (if the attributes are needed, they'd then be fetched later one at a time, one entity at a time), resulting in loads of DB accesses. So we change ResultSet.get_entity so that: * if the entity is already cached and has been instantiated from the same rset, it is returned as-is (to avoid loops) * if the entity is not yet cached, it is instantiated * if the entity is cached via another rset, its attribute/relation caches are completed Closes #9942503
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 tip