Re: [Rhythmbox-devel] rhythmdb design doc

[James Kahn <james liet net>]

Quoting Colin Walters <walters@verbum.org>:
> For ease of discussion, here's the DESIGN document.  I have been
> thinking about the different use cases, and I think the design will
> work, be faster, use less memory, and generally be easier to understand.
> But it could probably be improved; comments are appreciated!  

I think it looks pretty good.

> ** Multiple implementations
> 
> The interface should also permit multiple implementations.  For
> example, there are the crazy people out there who have all their
> music metadata in a SQL database already, so having our own
> database doesn't help them much.
> 
> It also may turn out that using something like SQLite could
> speed up Rhythmbox for large numbers of files (say > 6k or so).
> This is an area where the current Rhythmbox kind of falls over.
> So permitting multiple implementations will allow us more
> flexibility for experimentation.

This is definitely a necessity.  I'm not sure how much it would help people 
that already have their metadata in a DB.  Chances are it won't be in the 
format that rb wants.  They could of course change it ;).

We should also have a sensible default implementation that provides good 
performance without the user having to configure anything.  SQLite sounds 
pretty good, although I haven't used it.  The website for SQLite says it has 
been tested on Linux (and Windows).  Do we have to worry about any other 
platforms?

> *** But what about CD audio?
> 
> Should we support saving CD tracks in the database?  Should we
> be able to mix them with regular songs in a playlist?

IMHO, CDs are very different from the more permanent hard disk storage and 
should be viewed as another source in much the same way as Internet Radio is.  
The lifetime of the CD view should really be for the length of time the CD is 
inserted into the drive.  I'm sure there will be many different viewpoints as 
to what should be done here.

> ** What is a song?
> 
> Conceptually, it's just a collection of attributes.  The most
> important is the type, which says whether it's a local file,
> an internet radio station, etc.  Other attributes include
> location, track number, rating, last play time, play count,
> quality, etc.

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.

The downside of this is that it can use a lot more space - but space is cheap 
these days, and the performance impact can be pretty much negligible with a bit 
of denormalisation.
 
> **** 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?

> ** Multithread-capable
> 
> We need to be able to perform operations in multiple threads.
> However, the database should be optimized for common operations,
> and this definitely means reading.  Writing should be lower
> priority, although we don't want to completely starve writers.
> 
> Because we need to support multiple backends, we can only really
> support large-grained locking (i.e. one big global RW lock).
> SQLite for example only has one lock.

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

> ** Queries

*snip*

> 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.  

select * from songs where artist = 'Foo' and album = 'Foo's Greatest Hits';

Maybe we would do better to have more specific query functions, eg:

rhythmdb_do_entry_query_by_genre (db, "rock")
rhythmdb_do_entry_query_by_band (db, "The Beatles")
rhythmdb_do_entry_query_by_album (db, "The Beatles", "White Album")

Hmm, maybe they're not quite what I was thinking of, but you get the idea (I 
hope). 

> Then, we will make the main song view use this model:
> 
> gtk_tree_view_set_model (mainview, model);
> 
> However, suppose that the user clicks on a genre.  This will require
> several queries, because we need to filter the artist and album browsers
> by artists/albums which are in those genres.  As before, we filter the
> main
> view by the query:
> 
> GtkTreeModel *model = rhythmdb_do_entry_query (db,
> RHYTHMDB_QUERY_PROP_EQUALS, "genre", "Ambient", RHYTHMDB_QUERY_END);
> gtk_tree_view_set_model (mainview, model);
> 
> However, we also need to gather the lists of artists/albums.  We use the
> specialized query rhythmdb_do_property_query, which returns just a flat
> GtkTreeModel.  This call looks like this:

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.


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


-- 
James Kahn <james@liet.net>
http://liet.net