After thinking it over, I believe the concept of handles will fit my purpose very well (thanks again ApochIq!). The main task in front of me now is how best to use them in the GameDB system...

Being that the Database class should really just be a storage class, I think we need handle managers to be able to tap directly into this. If anything gets removed from the storage the handle managers should instantly reflect this - this means that the handle managers should be able to tap directly into the data.

The results sets returned will now hold only handles to the underlying data which must be resolved before any data can be accessed. This still raises an interesting question though given that a result set is effectively a 'view' of the data. If you delete an item from the database, all views should know of this and remove the data from the results sets themselves. I don't want a view to be rendered 'stale' because the data underneath has changed. This brings back my point of connected and unconnected recordsets. Sometimes we may want to have a snapshot of the data at a given time, whereas others we will want a live view. The best way I feel to acheive this is to run an internal messaging system and send out various messages whenever certain events occur.

The points raised about concurrency are valid. I can see this system being effectively run in another thread to fill up a few result sets and another thread being able to work with the sets whether filled or partially filled. The idea of results streams is springing to mind... I've never done any true MT programming before, so this aspect is going to be interesting to say the least.

I should perhaps clarify what sort of 'database' this is - I'm not sure :P It's not a relational database (of sorts). The database element is effectively based around both attributes and tags; entities are retreivable by specifying conditions on the tags and attributes they posess. There's no concept of a 'table' at all, so the strict classifications of C++ classes and relational theories of RDMS simply don't apply; what we have is tags, an object can be tagged with whatever you like and exist as part of multiple tag collections at one, or none at all. Relationships don't really exist, except that you can store handles to other entities as attributes of another entity. Entities can have new attributes added or removed with the API or via scripting, they can also have function attributes (so you can call functions on them). The action query side of the API will let you update the attributes of objects en-masse by specifying the selectivity conditions.



I'm happy to announce that Spotlight #1 is up, go read it on the frontpage. I'm playing the Starscape game by Moonpod as initial 'research' for another article. Their work is outstanding, very polished and I love being able to call playing games as research!