Re: [Fwd: Re: [CDBI] 2 Questions?]

[prev] [thread] [next] [Date index for 2005/09/15]

On Thu, Sep 15, 2005 at 02:34:40PM -0500, melo_am0@xxxxxxx.xxx wrote:
> > DBIx::Class gets round this by having a real 'new' method, which makes
> > life rather simpler (and also allows objects not in the db - create is
> > just a shortcut for ->new(...)->insert)
> 
> Sounds interesting. Would a transition to DBIx::Class be particuarly
> difficult?

If you only require Class::DBI functionality tested by the following
Class::DBI tests (from 0.999) -

# 01-columns.t
# 02-Film.t
# 03-subclassing.t
# 04-lazy.t
# 06-hasa.t
# 08-inheritcols.t
# 09-has_many.t
# 11-triggers.t
# 12-filter.t
# 13-constraint.t
# 14-might_have.t
# 15-accessor.t
# 16-reserved.t
# 18-has_a.t
# 19-set_sql.t
# 21-iterator.t
# 22-self_referential.t
# 30-pager.t
# 98-failure.t

then the DBIx::Class::CDBICompat layer should *in theory* be a drop-in
replacement for Class::DBI in your code, given the CDBICompat classes
pass those tests already.

This doesn't cover the wide array of plugins available though, although
DBIx::Class itself has join support equivalent to Class::DBI::Sweet's in
current trunk.

        -- 
             Matt S Trout       Specialists in perl consulting, web development, and
  Technical Director    UNIX/Linux systems architecture and automation. Mail
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

 + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +

_______________________________________________
ClassDBI mailing list
ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx
http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi