[orm] 40,000 feet outline idea

[Matt S Trout]

Before I start: The below outline is DBIC-centric *only* because that's what 
I'm most familiar with (well, and also because it was always meant to be a 
meta-ORM and most of the specific API stuff is contrib :), and where I'm sure 
others are ahead I've tried to note it, but I'm sure you guys can shed more light.

I *suspect* of all the projects involved, DBIx::Class has the most current 
momentum and the biggest active set of contributors so we should leverage that 
community, however that doesn't mean I'm looking for a takeover (and people 
have been splitting bits out of DBIC for use elsewhere already, it's a fine 
tradition and I'm happy to do it for technical or political reasons as 
required, or to throw half of it away if we come up with something better) - 
DBIC isn't really a dictatorship as it stands in any case, I've offered the 
idea of forming a core team up and been told "what's the point of adding 
beauraucracy when we make decisions by consensus anyway?".

So.

As I see it, what we need is -

1 ORMcore:
   A schema handler (DBIC's is an ok start and talks to SQL::Translator very 
well, which is now being actively developed by castaway who I've got 
subscribed to here. we'll need Object::Relation's magic or something 
equivalent to do OODBs right though)
   An SQL generator (DBIC was planning an AST->SQL thing approximating 
"SQL::Abstract with all the DWIM factored out somewhere else", there's 
probably a better idea since that plan was based on "shortest path to 
something sane")
   a set of DBD wrappers to handle inter-db weirdness (and gods but it would 
be nice for us to pool the fixes we already have between us ...)
   a storage dispatcher type thingy (DBIC's Storage::DBI is being tweaked to 
handle this, although I believe Data::ObjectDriver is *way* more advanced here)

1 OODB interface:
   Object::Relation ported to Moose would be about my ideal for this

1 ROM (relational -> object, i.e. db-is-primary) interface:
   a mix of the current DBIx::Class API and some JDBI bits (notably the 
$object->load stuff) would be my ideal based on current knowledge but I'm not 
familiar with most of the others.

1 general query handler:
   I don't know of anything that does the dataset handling at an abstract 
level better than DBIx::Class::ResultSet atm, so take that and factor out the 
SQL::Abstract-specific bits might be a thought here

N query interfaces:
   Jifty::Query and Object::Relation's style seem of the same type and look nice
   DBIC's SQL::Abstract interface works well enough and we'd maintain it for 
backcompat if nothing else (and we support group by + having there and at the 
resultset layer, dunno if anybody else does ...)
   I'd dearly love a more Tangram-y overload-based thing to go full-on LINQ-like

I'd have thought if we get the above right, everybody could have their cake 
and eat it by taking the cores of these components and 
subclassing/delegating/plugging/whatever to provide for their specific needs

If anybody's interested, prodding at the DBIx::Class result class stuff and 
the way it composes together features via MI + Class::C3 may be enlightening; 
it's certainly *a* WTDI and I have code that uses 2 of the about 20 "usual" 
components used by DBIx::Class::Core that works perfectly happily.

Comments, suggestions, flames, flying LARTs? :)