Re: Common music database?

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:

gtk-doc docs:

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):

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]