Re: [Banshee-List] Smartplaylists & normalized model

["Oscar Forero" <oforero novell com>]

Hello,

That may indeed be the solution, but that will still mean that for every
change in a given track (if the list is visible) the whole resultset
will have to be scanned and add what is not already in the model, the
biggest problem come from discovering which ones are not there any more,
so my guess is it will be in that case cheaper to clear the container
and re-add all tracks that are in the db view to the play list model,
this is the way in which banshee works right now, what i want to achieve
if that when changes in a single track are made, only that track has to
be reprocessed, as a matter of fact i already implemented something
similar in my normalized/browser patch (i will love to hear any
feedback). When you are browsing (let's say the genre Jazz) and you
change a property of a track to something that do not match the current
criteria the track will disappear of the view without any delay; that is
because i am firing an event and the models where this track is present
will refilter this track alone.

regards,

Oscar.

On Thu, 2006-03-30 at 14:21 +0000, Russ Brown  wrote:
> 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