[Dbix-class] design thought

[Todd Hepler]

Matt S Trout wrote:
> On Fri, Jul 29, 2005 at 06:22:47PM -0400, David Storrs wrote:
> 
>>On Jul 29, 2005, at 6:02 PM, Todd Hepler wrote:
>>
>>
>>>One of my frustrations with cdbi is that it is limited to DBI and  
>>>assumes that all the objects represent rows in a database.
>>
>>Not really.  It assumes that they are records in a backing store, but  
>>that backing store could be an RDBMS, a flatfile, or anything else  
>>that provides a conformant DBD module.
>>
>>Granted, the interface does use DB-centric terms like 'row' and  
>>'col', but those are pretty much synonymous with 'record' and 'field'  
>>in a more generic context.
>>
>>So yes, I think you can probably have exactly what you want--you just  
>>need to write the relevant DBD modules.
> 
> 
> You could probably also interrupt DBIx::Class at the point at which things
> enter the SQL/Table API, but that'd be far more work than either writing
> a DBD (there's already a DBD::LDAP, and I've made good use of DBD::AnyData's
> RAM storage in order to have virtual tables I can Storable into session data
> for web applications) or simple replace the storage engine once that's
> possible (or provide another engine for Rosetta, possibly).
> 

I haven't really looked into how difficult writing a DBD module would 
be.  Inventing some SQL-ish syntax for things that really aren't SQL 
databases (like filesystems and web pages) just seems kinda... clunky. 
The storage engine sounds like what I'm looking for.  The purpose for my 
post was to see if such a thing was part of the design/direction for 
this module.  I'm glad to see that it is.

-thepler