[MERGE] Add an InventoryEntry cache for xml deserialization
Robert Collins
robertc at robertcollins.net
Sat Dec 13 01:05:28 GMT 2008
On Fri, 2008-12-12 at 15:16 -0600, John Arbash Meinel wrote:
> "source string" ? You mean the 'value' for split-inv, or the raw line of
> xml for others?
yes.
> Anyway, I ended up running into some cache-lifetime issues, and figured
> it would be reasonable to open it up for discussion how we want to
> handle it.
>
> 1) Many, many, many tests re-use the same revision ids and file ids with
> different actual values. This is pretty trivial to fix by adding a
> "_entry_cache.clear()" as part of TestCase.setUp()
Or not using a global cache :>.
> 3) At one point I switched to having each XMLSerializer have its own
> entry cache, in case that was actually necessary. ATM I think it is
> actually a YAGNI.
Thats getting useful, because a repository will have lots of hits and
the lifetime is reasonably well defined, as long as repositories have
their own serializer instances, but IIRC we use singletons.
> 4) I've been considering restructuring things so that the repository
> passes the entry_cache to self._serializer.deserialize_inventory(),
> as this makes it obvious that the lifetime of the cache is bound to
> the Repository. Which helps for us to know that the caching rules
> won't be violated. The main downside is that something that ends up
> dealing with two mostly-identical repositories will not benefit.
>
> The original use-case I was trying to handle is the "extract all
> revision trees from the repository" which works just fine here, but
> there are other use cases where an entry cache would be helpful.
I'd be inclined to start with 4) and see how it goes.
> I've gone down a couple different routes, and right now I'm leaning
> towards having a single entry cache, and just clearing it out at
> appropriate times during the test suite. In the "real-world" if we had
> revision_id collisions, we would have much more serious problems than
> just inventory entry caching, so I'm considering the problem as mostly
> just a test suite not being properly isolated between test cases issue.
>
> Thoughts?
globals--
-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081213/0d627f91/attachment.pgp
More information about the bazaar
mailing list