Re: [Banshee-List] Some preliminary work in trunk - opinions needed

["Gabriel Burt" <gabriel burt gmail com>]

On Jan 2, 2008 3:09 AM, Scott Peterson <lunchtimemama gmail com> wrote:
> And I'm looking over the BansheeCacheableModelAdapter. I have a question and
> a concern. What is the benefit of querying from the CoreCache table? Does it
> just save the last state (sort &c.) of each model so that the sort operation
> doesn't need to be performed on startup? Does it do something more? The

Yes, the idea is to have the data filtered and sorted once, and do
fast limit/offset-based queries against that.  It used to be called
the CoreTracksCache table, but I renamed it because Albums and Artists
actually use it now too.  The queries to determine what Albums/Artists
to show are fairly complex because they are related to what tracks are
currently displayed.  The track query can be complex too if a user
uses the browser and/or searches.

> concern is that it appears the "ModelID" value being used to identify each
> model in the cache table is dependant upon the order in which models are
> instantiated (line 61 of BansheeCacheableModelAdapter.cs). Am I mistaken, or
> would changing the order of the model/cache-adapter instantiation screw up
> the cache on subsequent launches? If so, perhaps something a /little/ more
> sturdy should serve as the ModelID, like the hashcode of the model's class
> name. Or something.

The cache, as it is now, is not intended to live beyond a single
Banshee session.  It is actually cleared on start up.   Each cacheable
model is given a unique ModelID which could be different each run, but
that's ok.  It will be simple enough to change it if we need to
persist the cache.

Good questions, I'm glad to shed some light on this design decision.

Gabriel