It's been quite a while again since my last update, but I was waiting until something more interesting got finished than writing the same types of methods over for each DB table.
At this point, I believe I have all of the basic CRUD operations for the different tables finished. We can create new object types (video, tv show, documentary, ROM, album), attribute types (file name, plot, review, rating), relationship types (movie_has_actor, season_has_episode, album_has_song), artwork types (cdart, thumbnail, fanart, clearlogo), and create, update, and delete corresponding objects, attributes, relationships, and artwork. [Note: because I'm not working off of a full fork of XBMC, there is a column in the artwork table for storing the actual image file as a BLOB that I'm not yet implementing since it will be easier once my classes have access to some of the Texture utilities]
I have also completed methods to manage the bookmark, profile, settings, and stacktimes tables. One bit of particularly good news is that I have been able to use the exact same method signatures for things like adding artwork, setting bookmarks, and fetching stacktimes, so these things should act nearly the same as in previous versions.
My biggest project over the last week has been working on the table storing directory entries, which holds the metadata linking objects to the actual data in the file system (if applicable). In the current video database, there is a settings table and a streamdetails table. Settings stores things like zoom amount, selected audio stream, etc; streamdetails stores all the available video, audio, and subtitle streams. However, these tables could be very sparse. Now, the directory entry table has two columns, "settings" and "streams", which instead hold an XML string with these same details. I just finished writing methods which parse this XML and convert it into the same VideoSettings and StreamDetails objects as used before, and vice versa. Since this is all done in XML rather than a separate DB table, this also has the added benefit that a separate type of schema could be used if something like a picture needed file settings as well, perhaps storing changes made to saturation, contrast, things like that.
Among creating methods for CRUD operations, I have been scouring over the existing APIs for the video, music, pictures, and addon databases, trying to create all of the general methods I might need to facilitate changing the existing methods from using SQL to calling down to the generic object database. Furthermore, I finally moved from building my database from sqlite on the command line to implementing a the CreateTables method, which not only builds the database, but initializes it with "default" object, attribute, and relationship types so that, on start-up, XBMC would at least have all of the functionality it currently does.
Going forward from here, I'm working on two things. The first is creating something like the existing VideoInfoTag, PictureInfoTag, etc; more or less an ObjectInfoTag, that could fetch an object, a list of its associated attributes and (at least) IDs of other related objects. These leads me to the second, which is more work on the relationship front. I'm finding this to be the workhorse of this new set-up and I want it to be as efficient as possible. No more do we have all of these blank-link-blank tables; it's all done through relationships. So, we need to still be able to efficiently gather all actors in a movie or songs on an album. So, now that I think I can start adding a lot of test objects to the database and seeing how well my relationship methods work now and what more may be needed.
To wrap this up, I wanted to write a bit more about some exciting things with the way these relationships work.
- We, of course, still have moviesets, but, now, we also easily have one movie in multiple sets.
- When relating two objects, the relationship has a sequence index. This is used for sorting when fetching all related objects, but also for keeping track of things that should be numbered without adding an unnecessary attribute.
- So, things like episode number in a season, season number in a series, or track number on an album are managed through the sequence index rather than having to check the attribute list and then sort.
- I have, though, added a column called "link" to the relationship as well (brought over from 4.0a). The original purpose was defining actor roles. So, "movie_has_actor" and then the link value is the name of the role. But, I was thinking this could be used for other things, too. Like, "tvshow_has_episode". Sure Season 1 is the sequence index #1, but if the link is not null, we could give the season that name. I'm thinking of things like Avatar: The Last Airbender, where you might want to call Season One "Book One: Water", for example.
Sorry if this is a bit long-winded, but I'm excited about where this is going, now that most of the underlying functionality is almost finished.
Again, feedback is always welcome.