[Dbix-class] design thought

[Matt S Trout]

On Fri, Jul 29, 2005 at 05:02:27PM -0500, Todd Hepler wrote:
> Considering that the module name has already been chosen and it includes 
> "DBI", this idea may be a bit out of scope.  Nonetheless, I'd like to 
> throw it out there to see what people think.
> 
> One of my frustrations with cdbi is that it is limited to DBI and 
> assumes that all the objects represent rows in a database.
> 
> Consider making a call to retrieve() or search() as a request for 
> objects.  In the cdbi world then, DBI is responsible for fulfillment of 
> that request, and cdbi responds with objects.
> 
> Now say that, for some classes, I'd like to have something other than 
> DBI be responsible for fulfillment while having the resulting objects 
> conform to the same general interface.  Maybe people would contribute 
> plugins for different kinds of fulfillment engines.  For example:
> 
> @file = MyApp::File->search({dir => '/home/thepler/bin'});
> 
> And something knew that requests for the My::File class should use the 
> ::FileSystem (or whatever it might be called) fullfilment engine and it 
> would return objects that represent each file in my bin directory.

Right now the internals expect an sth; to allow for multiple back ends I'm
intending us to provide a well-defined interface for storage handling;
Rosetta for example uses its own storage handle and I'd like to be able to
co-operate with the Tangram system aswell.

Once this is in place (I'm thinking updatable cursors for search/update/delete
but not sure what do do about inserts) you should be able to back-end on
any storage engine you like. I've been thinking about an LDAP back-end and
possibly an XML one.

-- 
     Matt S Trout           Website: http://www.shadowcatsystems.co.uk
  Technical Director        E-mail:  mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.