[orm] 40,000 feet outline idea

[David Wheeler]

On Aug 14, 2006, at 12:21, Matt S Trout wrote:

> 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.

Thanks for getting us started, Matt. I've been meaning to do it  
myself for a few weeks. :-)

The folks I know of on the list so far are:

Jesse Vincent  (obra):       Jifty::DBI
Matt S Trout   (mst):        DBIx::Class
Ben Trott      (IRC nick?):  Data::ObjectDriver
David Wheeler  (Theory):     Object::Relation
Jess Robinson  (castaway):   SQL::Translator
Brandon Black  (blblack):    DBIx::Class::Loader

Anyone else?

My thought is that those of us who have worked on various Perl ORM  
solutions should get together, borg each other's work, and create an  
über Perl ORM. I'm thinking of something that has the caché of DBI  
for database interfaces in general, and that DateTime has for date  
and time manipulation. That is, to create a de facto standard for  
Perl hackers to use.

To that end, I've been trying to find the tuits myself to try them  
all out, but tuits have been in hopelessly short supply lately.

At any rate, I think that Matt and I are on the same page in terms of  
ideas. So I'll comment on his kickoff here from my limited point of  
view (which will necessarily be Object::Relation-centric.

> 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

I think that's true.

> 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)

This is probably the part of other ORMs that I'm least familiar with.  
But what I've been doing in O::R is trying to exploit the features of  
each database as deeply as possible, to make storage as correct and  
the interface as efficient as possible. That means some pretty  
complex schemas, of course, but the idea is to optimize the use of  
the database without the user of the ORM having to think about it.  
I'm not sure how that'd work with SQL::Translator; I'll have to check  
it out.

>   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 ...)

:-) I've just done PostgreSQL and SQLite so far. MySQL is on the  
roadmap.

>   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)

Yes. I *really* like the support for partitioning and Memcached  
caching on Data::ObjectDriver. I definitely think that kind of power  
and efficiency needs to be in our über ORM.

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

I'm going to try to find some tuits for this in the next few weeks.  
O::R currently uses Class::Meta, so a port to Moose probably wouldn't  
be *too* hard.

> 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.

I'm curious as to opinions on this: Should an ORM be a separate  
module from the übuer ORM? Or maybe we'd have a collection of modules  
that we distributed to address both needs/directions, and offer it as  
a best-of-breed solution?

> 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

Yes. I need to look at this more closely, too, as I'm not clear on  
the difference btween the "general query handler" and the "query  
interface". I'm sure that it's just some disconnect in my brain.

> 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 ...)

It's not unlike that offered by Class::DBI, too, IIRC.

>   I'd dearly love a more Tangram-y overload-based thing to go full- 
> on LINQ-like

I haven't used Tangram in years, and hated it when I did use it. I'll  
try to give it some time in the next few weeks, too. Maybe it'd make  
sense to involve Sam here? Or is he already subscribed?

> 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

Exactly.

> 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.

More stuff to look at. :-)

Best,

David