Re: [Rhythmbox-devel] rhythmdb design doc

[Colin Walters <walters verbum org>]

On Tue, 2003-08-26 at 22:30, James Kahn wrote:

> The website for SQLite says it has 
> been tested on Linux (and Windows).  Do we have to worry about any other 
> platforms?

I think it's actually a fairly portable piece of software.  But
regardless, we'll cross that bridge when we come to it, I guess.

> Do we want to keep a history of all times a song has been played, or every time 
> the rating has changed as well?  It could provide for some interesting data - 
> e.g., George listens to Avril Lavigne a lot but usually changes the song after 
> around 30 seconds when he gets sick of it.

Hm.  That seems to be slightly excessive to me, but if we can come up
with a practical use for it, then sure.
 
> > **** Saved/unsaved attributes
> > 
> > The database should support "temporary" keys, which are not actually
> > saved to the database on exit.  This is useful for sorting keys,
> > for example.
> 
> Could you elaborate on what temporary keys you think we'd require?

Just the sorting keys, for now.

> If we do everything within transactions is it even required for RB to have a 
> global DB lock?

Grabbing the database lock is what creates a transaction.

> > So here's how it will work in the new implementation.  When the user
> > clicks
> > on an album, this only requires one query.  So, we will just call
> > rhythmdb_do_entry_query like this:
> > 
> > GtkTreeModel *model = rhythmdb_do_entry_query (db,
> > RHYTHMDB_QUERY_PROP_EQUALS, "album", "Foo's Greatest Hits",
> > RHYTHMDB_QUERY_END);
> 
> A hypothetical question.  What if there are two bands "Foo" and "Bar", who both 
> have albums titled "Foo's Greatest Hits" (Bar just think they're funny guys).  
> You're going to strike a problem there.  rhythmdb_do_entry_query isn't enough 
> for this situation.  

That is a good point.  We should probably instead pass integer IDs
around.

> This could be a really stupid idea but may help the locking/transaction thing:
> 
> rhythmdb_do_entry_query_genre (db, genremodel, artistmodel, albummodel, "rock")
> 
> - could query all of them in a single transaction and populate the treemodels.

Well, setting the models will all be done with the lock held anyways, so
this should be equivalent.

> I don't have enough time at the moment to respond to the rest.  Hopefully this 
> has been a bit helpful...

Yep, it has.  Definitely need to fix the query API at least.