Re: [Banshee-List] Smartplaylists & normalized model

["Oscar Forero" <oforero novell com>]

Hello,

That makes a lot of sense, but what i mean by reloading the model is
re-creating the TrackInfo Objects and adding them to the appropriate
store for show in a view. All the TrackInfo objects already exist in
memory because they are loaded by the library object, the problem i see
with the view is that AFAIK you do not get an event for new and deleted
rows, so you will have to rerun the query all the time a track is
changed, and then work through all the results to add the new and remove
the missing or clearing the model and reloading all the results of the
view. 

I think views are great, but i am not aware that they are event driven
which i think is what is need it for this situation. I do something like
that for the browser, and for the current lists in my patch. Is not that
views are slow, all the post processing required will be slow.

Again i could be wrong....

regards,

Oscar.


On Thu, 2006-03-30 at 13:35 +0000, pickscrape gmail com wrote:
> 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