Re: Object Oriented Storage
Posted by: Jake Yazici
Date: October 13, 2005 08:03PM
Thanks for the input. I've considered similar scenarios (i.e. serialization to blob storage), but I couldn't wrap my head around how to support locks for it in multi-user environment, especially if someone accesses a root object composed of all persisted objects. I suppose this is a problem of any native object store.
However, I have warm'n'fuzzies for the concept of wrapping the client API for a relational view. Of course, all of this implies the need to build a custom ODBC/OLEDB driver to support third-party apps that only understand those protocols.
In my research, I have found many interesting implementations and concepts for for going the other way (i.e. relational storage that provides object synthesis). Hibernate, and its .NET port, Nhibernate, are champs!
I also found that the prevalence engines were interesting (http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ). There is a .NET port of this code as well, called Bamboo.NET.
The cute feature about these prevalent systems is that data modifications are first immediately saved as atomic transactions to a transaction log. Then, the transaction log is replayed to commit changes to the live object tree. The live object tree is periodically committed to disk, and the transaction log is flushed. All objects are accessed via the prevalence interface, which just spits out the objects. I remember that there is a root prevalent object that you proxy through or request all other objects. Pretty quick'n'easy... but lacks a SQL/relational interface. Also, the engines want to keep all objects in memory… which can be prohibitive too.
Yet, to extend the prevalence engines into providing a relational interface, check this thought:
What if the transaction log could be tee-d to a daemon/service that translates the transactions from the log into common SQL which is applied to a correlated relational store? Neat! In the other direction, the daemon would be called from triggers on commits to the rdb and would be used to update the object tree based upon changes to the relational data.
Of course, again, there are issues of multiple points of failure, synchronization of relational schemas to persistent domain object model… And instead of presenting the opposite interface for a given storage type, this approach would just create two different datastores (for the same data) and keep them synchronized, which unfortunately means approximately twice the storage space needed to accommodate both. Yeaaachhh...