Re: [CDBI] DBIx::Class::CDBICompat unofficial alpha
Michael G Schwern <[email protected]> Tue, 12 Jun 2007 10:32:48 -0700
| Newsgroups | gmane.comp.lang.perl.modules.class-dbi |
|---|---|
| Message-ID | <[email protected]> |
Rolf Schaufelberger wrote: > 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 ? In short, yes you can. CDBICompat results in regular DBIC objects. CDBICompat is a series of plugins taking advantage of Class::C3's "next::method". It adds in any CDBI methods that DBIC does not have and you still have access to DBIC behaviors. Methods that CDBI and DBIC have in common have their behaviors changed to match CDBI but since DBIC and CDBI are already rather similar nothing has fundamentally been changed. For example, because $cdbi_object->search() just calls DBIx::Class's search() you can use all the extra parameters provided by DBIx::Class like prefetch, join, page, having and distinct which provide much more efficient search queries than CDBI. You can also use DBIx::Class methods like count(). Not only does this allow you to move your app from CDBI to DBIC class by class, table by table but also *line by line*. You can use DBIC methods and features as you see fit without having to change the class declaration. > Otherwise, is it worse to use CDBICompat ? What 's the benfit ? Do I have to > use CDBI syntax ? DBIC would seem to be better technology than CDBI. [1] CDBI is approaching 10 years old and some design decisions I made at the start have turned out to be restrictive. DBIC has the benefit of 10 years of ORDM development in Perl to draw from. I was going to do a bunch of performance work on CDBI and it turns out DBIC already offers most of it. The benefit of CDBICompat is it provides the tools to make my app faster without having to immediately rewrite the whole app. Just dropping it in place doesn't actually make my app faster, in fact I wouldn't be surprised if it were a little slower. But I can now find the bottlenecks in my code, such as expensive expansion of related objects, and use new DBIC features (prefetch) to do them more efficiently. In addition, CDBICompat is implemented as a series of features that you can add and remove. For example, lazy column loading is one. Because my app doesn't take advantage of lazy loading I can remove the code which implements it thus speeding up column accessors. [1] I hedge on this because I don't have enough practical experience yet with DBIC to know for sure.