Re: [Banshee-List] Smartplaylists & normalized model

[Russ Brown <pickscrape gmail com>]

On Thu, 2006-03-30 at 15:48 +0200, Oscar Forero wrote:
> 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....
> 

Oh, I see... I've been working with SQL database in the stateless web
world for so long that I forgot about the nuances of stateful
development. :)

In that case my experience is diminished for this discussion, but allow
me to throw a further idea into the hat.

I presume that tracks have some sort of identifying ID. I'd imagine that
there will also be some ID-based hash of track IDs to TrackInfo object
references so that they can easily and quickly be looked up by ID. In
this case, you could have your views simply return a list of Track IDs.
When you display the smart playlist, you query the view, and run through
the list of IDs returned, adding references to the already-existing
TrackInfo objects to the container that represents your playlist. You
could re-run the query whenever a smart playlist is displayed or when a
track is update while the playlist is displayed. The query itself would
run very quickly. I don't know for a fact how fast it would be to run
through the IDs returned and re-populate the view container with a new
set of references, but since we're only talking about references here
and not full objects, I'd imagine not long at all.

I could be wrong: as I say my experience in stateful development is a
little rusty. :)

> 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
> 
> _______________________________________________
> Banshee-list mailing list
> Banshee-list gnome org
> http://mail.gnome.org/mailman/listinfo/banshee-list
-- 

Russ