Re: [CDBI] using closures for inflate and deflate

[prev] [thread] [next] [Date index for 2005/11/02]

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


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