[CDBI] using closures for inflate and deflate

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

--===============1865246768==
Content-Type: multipart/alternative; 
	boundary="----=_Part_6621_7836782.1130960809186"

------=_Part_6621_7836782.1130960809186
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I recently discovered when I upgraded Class::DBI from v3.0.1 to v3.0.11 tha=
t
some of my inflate/deflate methods no longer work. It appears that beginnin=
g
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)

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. I=
t
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 withi=
n
the sub itself.

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? Should I just
create my own select and after_set_$column triggers rather than using has_a
for non-"table relationship" relationships?

Thanks for any suggestions/feedback you might have,
Brian

------=_Part_6621_7836782.1130960809186
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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:<br>;
<pre>Fixed bug with shared meta_info (Will Ross)</pre>
Up to now, I've used the inflate/deflate functionality occasionaly as a clo=
sure.&nbsp; For example (very contrived):<br>
<br>
<span style=3D"font-family: courier new,monospace;">my $secret =3D &quot;pa=
ssword&quot;;</span><br style=3D"font-family: courier new,monospace;">
<span style=3D"font-family: courier new,monospace;">__PACKAGE__-&gt;has_a(m=
y_password_col =3D&gt; &quot;My::Blowfish&quot;, <br>
&nbsp;&nbsp;&nbsp; inflate =3D&gt; sub { My::Blowfish-&gt;new(shift,$secret=
) }, <br>
&nbsp;&nbsp;&nbsp; deflate =3D&gt; &quot;encrypt&quot;<br>
);</span><br style=3D"font-family: courier new,monospace;">
<br>
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.<br>
<br>
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.&nbsp; 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.<br>
<br>
Is this just Bad Practice(R) to do this kind of thing?&nbsp; Is there
any hope that dclone will be dropped from that _extend_meta
method?&nbsp; Should I just create my own select and after_set_$column
triggers rather than using has_a for non-&quot;table relationship&quot;
relationships?<br>
<br>
Thanks for any suggestions/feedback you might have,<br>
Brian<br>

------=_Part_6621_7836782.1130960809186--


--===============1865246768==
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

--===============1865246768==--