[CDBI] using closures for inflate and deflate

Brian Phillips bpphillips at gmail.com
Thu Nov 3 14:42:16 GMT 2005


As requested, I've created a failing test case and posted it on
rt.cpan.org<http://rt.cpan.org>here:
http://rt.cpan.org/NoAuth/Bug.html?id=15498

On 11/2/05, William Ross <will at spanner.org> wrote:
>
> On 2 Nov 2005, at 19:46, Brian Phillips wrote:
>
> > I recently discovered when I upgraded Class::DBI from v3.0.1 to
> > v3.0.11 that some of my inflate/deflate methods no longer work. It
> > appears that beginning in version 3.0.9, the _extend_meta method in
> > Class/DBI.pm uses Storable to do a dclone on the meta info. I'm
> > not sure of the reasoning behind this apart from what's in the
> > Changes file:
> > Fixed bug with shared meta_info (Will Ross)
>
> In versions up to 3.0.8 there was a failure to dereference the
> meta_info hash properly in cases where we were inheriting
> relationships from a base (or other super-) class. Rather than fix
> this particular case, Tony preferred to use dclone and avoid all such
> problems.
>
> http://rt.cpan.org/NoAuth/Bug.html?id=14878
>
> > Up to now, I've used the inflate/deflate functionality occasionaly
> > as a closure. For example (very contrived):
> >
> > my $secret = "password";
> > __PACKAGE__->has_a(my_password_col => "My::Blowfish",
> > inflate => sub { My::Blowfish->new(shift,$secret) },
> > deflate => "encrypt"
> > );
> >
> > This kind of functionality stopped working because once that
> > anonymous sub (closure) was run through Storable::dclone, it no
> > longer had access to the $secret variable.
> >
> > I realize there's a million ways to do the above differently but it
> > becomes more challenging when I want to auto-generate a bunch of
> > 'has_a' columns. It was very nice to be able to create those
> > anonymous subs on the fly without having to do a string evaluation
> > or specify every variable explicitly within the sub itself.
>
> Lost here. I assume you're not defining has_a relationships during
> inflation, so you mean that you want to use the same inflation and
> deflation methods for all the relationships? Which should just work:
> coderefs and method names can be supplied as before. Unless the
> inflation subs are all closures that need to know $something. Lost
> and now also scared.
>
> > Is this just Bad Practice(R) to do this kind of thing? Is there
> > any hope that dclone will be dropped from that _extend_meta method?
>
> I doubt it. He seems to be ideologically committed to the Most
> General solution. But then Tony does love his closures, so it's worth
> taking up.
>
> > Should I just create my own select and after_set_$column triggers
> > rather than using has_a for non-"table relationship" relationships?
>
> No! bad triggers, bad. better to supply your own _extend_meta method.
> imho.
>
> ... and I'd be very interested to see a fuller example of the thing
> you used to do and now cannot.
>
> best
>
> will
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digitalcraftsmen.net/mailman/private/classdbi/attachments/20051103/7e4e085b/attachment.html


More information about the ClassDBI mailing list