Re: [Banshee-List] Smartplaylists & normalized model

[Russ Brown <pickscrape gmail com>]

On Thu, 2006-03-30 at 14:42 +0200, Oscar Forero wrote:
> Hello,
> 
> I have been following the discussion about the Smart play lists and i
> will like to contribute with my ideas about the subject.
> 
> First i do not think that the way of leaving that to the database,
> either working with views or selects will bring a great performance to
> the application, specially because you will be force to reload the whole
> model from the DB every time something change in one track, i think the
> best to go is to have only one store and filter those using stacked
> models, i already did that change for my normalized patch. I also
> replaced the normal play list mechanism to use a TreeModelFilter on top
> on a ListStore, in the future we could replace those store by 100%
> managed ones to reduce the amount of marshaling that occurs, but for the
> moment appear to be working good enough.
> 
> I think Smart play list could work exactly the same way only using a
> dynamically generated filter, then the live update will come for free
> without any reloading of the model.
> 

If views in sqlite work anything like they do in PostgreSQL (and I think
they do) then they basically work like SELECT macros. I'm not sure what
you mean by having to reload the entire model to use views: we're
talking about a simple select statement. If you're suggesting that it
would be quicker to store the entire music catalogue in memory and
search it using custom C# code then you're going to find that it is not
going to be anywhere near fast as using SQL for that purpose. High-speed
filtered data retrieval is what SQL excels at, especially with a good
normalised data model and sensible indexing. You'll most likely find
that any view you create will returns its results in microseconds,
whereas coding a filter in C# may take tenths of a second or even
longer, depending on the complexity of the filtering and size of the
source data. 

Note that my belief in using views only holds water if banshee updates
the tracks table whenever a track is changed (which I'd be surprised if
it doesn't). Also note that with a database the size of banshee's the
entire database is likely to be cached in memory anyway, so querying
from it won't involve any disk IO.

> Please take a look of my current Browser implementation, you can change
> the Genre of a track and that will disappear automatically from the
> Genre view, this also do not put a lot of load into the processor
> because only that one track is reprocessed. And we could add some View
> caching to have the pre-filtered models/views already in memory, there a
> balance will be needed between speed and resource usage but i think is a
> good way to solve the issue.
> 
> To do the check apply the patch to a clean 0.10.9, better if you use CVS
> to get it and autogen to configure it.
> 
> Sorting is deactivated because the implementation of TreeModelSort is
> crap, if i set that then out of nothing rows start to disappear every
> time you browse until an unknown exception is thrown. To my
> understanding the Sort model should not change the visibility of any of
> the rows so this has to be a bug in the way they implemented. I think i
> will have to create my own implementation of this but i do not have
> enough time this week.
> 
> After checking the browser go to a genre/artist/album and change the
> value in one of the tracks for something different to the value you have
> selected. The track should disappear of the list!
> 
> Please check it, also you Aaron if you happen to have 30 free minutes.
> 
> Regards,
> 
> Oscar. 
> 
> 
> _______________________________________________
> Banshee-list mailing list
> Banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list
-- 

Russ