catalystattrout.me.uk
Jul 25, 2005, 7:17 AM
Post #1 of 1
(690 views)
Permalink
|
|
Annouce: DBIx::Class, a.k.a "taking the easy way out"
|
|
(this mail also sent to cdbi-talk but my posting address is different)
People are constantly complaining on this list that Feature X hasn't made it
into Class::DBI etc. etc. or that it's too monolithic or too slow or whatever.
I considered attempting to work towards making this easier to fix by gradual
refactoring. After a week of giving myself a headache, I understood why Tony
isn't already halfway through - it's *hard*, especially if you're going to
maintain the API and the stability that so many Class::DBI users rely on.
So I'm taking the easy way out - start from scratch. Well, start by looking
at Class::DBI, working out which are the core features, and then build
something nice, clean and extensible that provides those and the means to
add extra features - up to a full Class::DBI compat layer in one direction,
and a full recordset-oriented ORM with implicit joins in another. I've
already laid some of the groundwork for the latter in a generic relationship
system (no it doesn't do views yet, no it doesn't do as much as Class::DBI
yet, no that's not the point) and got a fair way towards a good impression
of the former (aka it passes quite a few of the 0.999 tests).
The model I've chosen is total pluggability via NEXT - so multiple
inheritance is entirely the order of the day. This is a little mind-breaking
to start with, but means that each class (plugin? hard to say where core stops
and plugins start) can stand relatively on its own - e.g. my has_a
emulation doesn't require any of the other cdbi compat plugins to work,
although if you're expecting it to behave exactly as the Class::DBI one does
you need several more. The result is something a tad more modular than
Class::DBI - the compat layer is currently 16 separate classes.
So far as I'm concerned, this is a *research project* for the moment. There's
no documentation (bar cross-referencing the Class::DBI docs and which of the
tests it passes), the API is fairly bare, and I'm intending to refactor
heavily as I go along so *everything* in there is subject to change at any
time without any warning or justification (bar a brief commit message).
For those of you still reading, svn is at
http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Comments, suggestions, questions and flames welcome. More tests or patches to
pass more of the cdbi tests are even more welcome. Patches that refactor the
code in such a way as to clean up the architecture or extra classes that do
something interesting would be best of all.
Oh, and if anybody fancies doing something odd but keeping some shared code,
track me down on #catalyst and I'll help you set up a local branch with the
assistance of either svn or svk.
And before anybody asks, No I Am Not Releasing It To CPAN Right Now. If you
don't have svn/svk around and the will to use them, this is *not* for you.
Yet. :)
--
Matt S Trout Website: http://www.shadowcatsystems.co.uk
Technical Director E-mail: mst (at) shadowcatsystems.co.uk
Shadowcat Systems Ltd.
|
