Re: [CDBI] DBIx::Class::CDBICompat unofficial alpha

On Montag 11 Juni 2007, Michael G Schwern wrote:
> Several moons ago I posted that I was going to be doing some performance
> work on Class::DBI.
> http://lists.digitalcraftsmen.net/pipermail/classdbi/2007-February/001517.h
>tml
>
> People pointed out that DBIx::Class has a lot of the features I needed and
> has a CDBICompat library already.  Unfortunately, CDBICompat wasn't a good
> enough emulator of CDBI to handle my existing app.  Still, DBIC's features
> and performance proved enticing enough to improve CDBICompat.
>
> After a few months of working on it on-and-off its now at a state that it
> can handle my large, twisty CDBI app.  Before putting it into production
> I'd like others to beat on it with a few sticks, see if they can shake out
> more problems.  It currently resides in my local SVK repository but I'll be
> merging it into the DBIC repo soon.
> http://schwern.org/~schwern/src/DBIx-Class-0.07006_CDBICompat_01.tar.gz
>
> I've attached my log so folks can get a feel for what's been done.
>
> I must say, I'm impressed with the way Class::C3 and its next::method()
> allows slicing up modules by feature and how it allows code to use a mix of
> CDBI and DBIC behaviors.
>
> There's a pile of new tests in CDBICompat that can be merged back into
> CDBI. Also the CDBICompat tests are based on an old test suite and I need
> to merge in the latest tests.
>
>
> Here's the caveats about CDBICompat I've noted.
>
> * You can no longer treat $obj->{column} and $obj->column as synonyms.
>
> Its wrong, but you can get away with $obj->{column} in CDBI if you're sure
> the columns have been fleshed out.  People do this to bypass lousy accessor
> performance.  This will not work in CDBICompat, DBIC stores columns
> elsewhere.
>
> This proved to be the single largest and most pervasive incompatibility. 
> If anyone can think of a way to detect when $obj->{column} is accessed I'd
> like to hear it.  Some sort of tricky self-tie maybe.  I'd also like to
> know if anyone has an idea of how it can be emulated.
>
>
> * The class' table or columns must be declared as early as possible.
>
> CDBI does most of its work just-in-time.  DBIC does its setup early on.
> CDBICompat uses table() and columns() to trigger DBIC's setup.  Without it,
> nothing works.
>
> A consequence of this is you need to declare a foreign table's table() and
> columns() before you try to make a relationship with it.  This means you
> can't put your relationship declarations in the same module as your table()
> and columns() declarations which I find awkward.
>
> This is the #2 incompatibility from where I stand.  Again, better ideas
> welcomed.
>
>
> * insert() is no longer a way to get around an overriden create()
>
> Foo isa CDBI.  Foo::create() exists.  But Foo->insert() calls
> Class::DBI->insert.  This is a bug in CDBI that some people exploit to jump
> over an overridden create().  It should probably be fixed in CDBI (change
> *create = \&insert; to sub create { $self->insert(@_) }.  I fixed it in
> CDBICompat and I think it should stay that way.
>
>
> * $obj = $obj->retrieve($obj->id) will not necessarily give you a fresh
> copy of the object.
>
> If you want to clear out the object use $obj->discard_changes().  If your
> object has special data and stuff, override discard_changes() to clear that
> stuff out, too.
>
> I'm not sure why this is so.  Better ideas welcomed.

We're using Class::DBI as well in a large app and we've tried out DBIC too.  
Now when I use CDBICompat, does it allow me to move my app class by class 
(table by table) to "plain" DBIxC ? 
Otherwise, is it worse to use CDBICompat ? What 's the benfit ? Do I have to 
use CDBI syntax ?


-- 
Regards
Rolf Schaufelberger


plusW
Rolf Schaufelberger 
Beim Brünnele 6        Tel. 49 7181 994 35 50
73614 Schorndorf       Fax. 49 7181 994 32 75
[email protected]