[CDBI] re-casting cdbi classes?

Ben Lavender blavender at gmail.com
Tue Mar 28 13:24:40 BST 2006


My goodness.

I posted this on a Friday afternoon before a few days off--oops. 
Never again!   I apologize for posting a question and not being able
to read responses right away.

At any rate I have many good ideas to try--overriding new and
threshholds appealing to me the most.  Much to experiment with.

Most on spot, though, was the advice not to muck with CDBI's
internals.  I've had to make a few convoluted SQL queries in
association with this unfortunate schema, and just using set_sql was,
although less maintanable, was by far the better solution than any of
the various search methods, addons, and alternatives.  Just let CDBI
do what it does well and don't ask too much of it and it will do fine!

Thanks to all who responded, I appreciate it.

Ben



On 3/23/06, William Ross <will at spanner.org> wrote:
>
> On 23 Mar 2006, at 01:33, Matt S Trout wrote:
>
> > William Ross wrote:
> >> On 18 Mar 2006, at 22:35, Ben Lavender wrote:
> >>> Hi all,
> >>>
> >>> I've come across a situation where a client needs a change in
> >>> requirements which would, ideally, require a slight slight breaking
> >>> out of one class into a base class and two sub classes.  Put
> >>> shortly,
> >>> I have an event which is based on due dates right now, but some
> >>> classes of events are turning up which need to be done based on
> >>> mileage instead.
> >> Class::DBI doesn't like data classes to inherit from one another,
> >> and I very much doubt that it would like objects to switch from
> >> one data class to another after they've been retrieved. I'm sure
> >> it could be made to work, but the way cdbi holds closures at class
> >> level and its increasing use of plugins make it fairly horrible to
> >> debug that kind of code, or it does for me anyway.
> >
> > Inheritance was fine as of 0.96 before Tony started doing Odd
> > Things With Closures. Class::DBI::Frozen::301 may work here.
>
> As far as I remember Odd Things With Closures have been a key part
> (and/or goal) of the Class::DBI project ever since the early Schwern
> versions, but it's true that they don't achieve their full
> incomprehensibility until combined with Tony's enthusiasm for
> pluggable overrides.
>
> > DBIx::Class' inflate_result method which can be overridden to
> > rebless trivially is a better solution, but probably impossible to
> > backport.
> >
> >> My advice, based on 8ish years of repeatedly trying to bend cdbi
> >> out of shape, is don't. Do it the official cdbi way or find
> >> another ORM that matches your problem better: there's plenty of
> >> choice now.
> >
> > I've bent CDBI out of shape successfully a fair few times
>
> Me too, and it can be good healthy fun. In this case the approach
> that Perrin suggested sounds excellent and very workable. I just
> wanted to sound a note of caution because in my experience once
> you've hacked a chunk out of cdbi you have to pay very close
> attention to every point release, and who has that kind of time any
> more? Whereas if you stay within the boundaries of normal use, it's
> actually pretty good at continuing to work.
>
> will
>
>
> _______________________________________________
> ClassDBI mailing list
> ClassDBI at lists.digitalcraftsmen.net
> http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi
>




More information about the ClassDBI mailing list