[Dbix-class] design thought

Matt S Trout dbix-class at trout.me.uk
Sat Jul 30 18:08:17 CEST 2005

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.

More information about the Dbix-class mailing list