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
Tue, 12 Jan 2016 17:36:28 +0100 [rset] refactoring of _build_entity method
Alexandre Richardson <alexandre.richardson@logilab.fr> [Tue, 12 Jan 2016 17:36:28 +0100] rev 11168
[rset] refactoring of _build_entity method define a method for entity instantiation and storage in cache (related to #9942503)
Thu, 25 Feb 2016 09:28:21 +0100 [entity] comparing two entities returns NotImplemented
Julien Cristau <julien.cristau@logilab.fr> [Thu, 25 Feb 2016 09:28:21 +0100] rev 11167
[entity] comparing two entities returns NotImplemented Fixes a test when using some versions of unittest2, where assertItemsEqual tries a sort and expects TypeError, which it doesn't get if we directly raise NotImplementedError. The NotImplemented value is treated specially by the interpreter: https://docs.python.org/3.4/library/constants.html#NotImplemented
Thu, 18 Feb 2016 09:24:43 +0100 [test] replace one use of lgc.testlib.unittest_main with unittest.main
Julien Cristau <julien.cristau@logilab.fr> [Thu, 18 Feb 2016 09:24:43 +0100] rev 11166
[test] replace one use of lgc.testlib.unittest_main with unittest.main
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 tip