Re: [CDBI] using closures for inflate and deflate
[prev] [thread] [next] [Date index for 2005/11/03]
From: Brian Phillips
Subject: Re: [CDBI] using closures for inflate and deflate
Date: 14:42 on 03 Nov 2005
Subject: Re: [CDBI] using closures for inflate and deflate
Date: 14:42 on 03 Nov 2005
--===============1323632136== Content-Type: multipart/alternative; boundary="----=_Part_15411_27686615.1131028936634" ------=_Part_15411_27686615.1131028936634 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=3D15498 On 11/2/05, William Ross <will@xxxxxxx.xxx> 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=3D14878 > > > Up to now, I've used the inflate/deflate functionality occasionaly > > as a closure. For example (very contrived): > > > > my $secret =3D "password"; > > __PACKAGE__->has_a(my_password_col =3D> "My::Blowfish", > > inflate =3D> sub { My::Blowfish->new(shift,$secret) }, > > deflate =3D> "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 > > ------=_Part_15411_27686615.1131028936634 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline As requested, I've created a failing test case and posted it on <a href=3D"= http://rt.cpan.org">rt.cpan.org</a>; here: <a href=3D"http://rt.cpan.org/NoA= uth/Bug.html?id=3D15498">http://rt.cpan.org/NoAuth/Bug.html?id=3D15498</a><= br><br> <div><span class=3D"gmail_quote">On 11/2/05, <b class=3D"gmail_sendername">= William Ross</b> <<a href=3D"mailto:will@xxxxxxx.xxx">will@xxxxxxx.xxx</= a>> wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-left:= 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex= ;"> On 2 Nov 2005, at 19:46, Brian Phillips wrote:<br><br>> I recently disco= vered when I upgraded Class::DBI from v3.0.1 to<br>> v3.0.11 that some o= f my inflate/deflate methods no longer work. It<br>> appears = that beginning in version=20 3.0.9, the _extend_meta method in<br>> Class/DBI.pm uses Storable to do = a dclone on the meta info. I'm<br>> not sure of the reasoning= behind this apart from what's in the<br>> Changes file:<br>> Fixed b= ug with shared meta_info (Will Ross) <br><br>In versions up to 3.0.8 there was a failure to dereference the<br>m= eta_info hash properly in cases where we were inheriting<br>relationships f= rom a base (or other super-) class. Rather than fix<br>this particular case= , Tony preferred to use dclone and avoid all such <br>problems.<br><br><a href=3D"http://rt.cpan.org/NoAuth/Bug.html?id=3D148= 78">http://rt.cpan.org/NoAuth/Bug.html?id=3D14878</a><br><br>> Up to now= , I've used the inflate/deflate functionality occasionaly<br>> as a clos= ure. For example (very contrived): <br>><br>> my $secret =3D "password";<br>> __PACKAGE__-&= gt;has_a(my_password_col =3D> "My::Blowfish",<br>> &nb= sp; inflate =3D> sub { My::Blowfish->new(shift,$secret) }= ,<br>> deflate =3D> "encrypt" <br>> );<br>><br>> This kind of functionality stopped working beca= use once that<br>> anonymous sub (closure) was run through Storable::dcl= one, it no<br>> longer had access to the $secret variable.<br>><br> > I realize there's a million ways to do the above differently but it<br= >> becomes more challenging when I want to auto-generate a bunch of<br>&= gt; 'has_a' columns. It was very nice to be able to create those= <br>> anonymous subs on the fly without having to do a string evaluation <br>> or specify every variable explicitly within the sub itself.<br><br= >Lost here. I assume you're not defining has_a relationships during<br>infl= ation, so you mean that you want to use the same inflation and<br>deflation= methods for all the relationships? Which should just work: <br>coderefs and method names can be supplied as before. Unless the<br>infl= ation subs are all closures that need to know $something. Lost<br>and now a= lso scared.<br><br>> Is this just Bad Practice(R) to do this kind of thi= ng? Is there <br>> any hope that dclone will be dropped from that _extend_meta method= ?<br><br>I doubt it. He seems to be ideologically committed to the Most<br>= General solution. But then Tony does love his closures, so it's worth<br> taking up.<br><br>> Should I just create my own select and after_set_$co= lumn triggers<br>> rather than using has_a for non-"table relations= hip" relationships?<br><br>No! bad triggers, bad. better to supply you= r own _extend_meta method. <br>imho.<br><br>... and I'd be very interested to see a fuller example of = the thing<br>you used to do and now cannot.<br><br>best<br><br>will<br><br>= </blockquote></div><br> ------=_Part_15411_27686615.1131028936634-- --===============1323632136== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ClassDBI mailing list ClassDBI@xxxxx.xxxxxxxxxxxxxxxx.xxx http://lists.digitalcraftsmen.net/mailman/listinfo/classdbi --===============1323632136==--
 |
[CDBI] using closures for inflate and deflate
|
|
 |
Re: [CDBI] using closures for inflate and deflate
|
|
|
|
Re: [CDBI] using closures for inflate and deflate
|