Re: Common music database?

["Milosz Derezynski" <internalerror gmail com>]

Well umm wrg to the "arbitrary query language", one of our developers
has developed a relation type library which makes it possible to treat
relations (as they are presented in SQL databases) as data types, based
on GObject:

General Introductory docs:
http://bmpx.beep-media-player.org/site/Database_backend

gtk-doc docs:
http://bmpx.beep-media-player.org/docs/holyrel/

which we use in our player, and it's far more efficient than using
sqlite3, the only thing we're currently lacking are trasactions.

Why i'm saying this is that i don't want to be _this_ hard-tied to
sqlite3. Sqlite3 can be the _storage_ backend, but i don't think
everyone should be forced to actually use sqlite3 as the direct
container for the metadata, erh, if you get what i mean.

I've written a HRel to Sqlite3 connector which stores the data inside
sqlite3 tables, but we usually manipulate with the relations ("tables")
and tuples ("rows") in memory using normal C operations and no SQL at
all, and the connector merely uses sqlite3 to store the data between
session, and to load it back when the app starts up again.

Normally, we use a small filesystem-like thing i've written to store
the database beetween sessions called RTFS (Relation/Tuple Filesystem):

http://websvn.beep-media-player.org/filedetails.php?repname=bmpx&path=%2Ftrunk%2Fsrc%2Frtfs.c&rev=0&sc=0

rtfs.c isn't very elaborate nor complex, but that's because it's only
the raw storage of the tables, something like the storage driver for
mysql maybe if that's an appropriate comparison, the whole logic
happens in libhrel itself.

That all said, i'd really don't like to be forced to use sqlite3 as the
actual backend for storing _and_ manipulating our database:

Storing trough sqlite3: OK
Manipulating trough SQL using sqlite3: Not _really_ ok...

(from our app's and my standpoint)

-- Milosz

http://bmpx.beep-media-player.org