[CDBI] RFC: CDBI::Sweet prefetch

[prev] [thread] [next] [Date index for 2006/02/07]

--===============1585163703==
Content-Type: multipart/alternative; 
	boundary="----=_Part_6569_1872237.1139274199789"

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

I sent an email earlier about using "LEFT JOIN" with CDBI::Sweet's prefetch
attribute. I've hacked together a version that works for me, and retains
backwards compatibility with the existing prefetch attribute. I'd like to
clean it up and submit it as a patch, but I want to make sure the interface
is reasonable first.

Currently, "prefetch" allows you to specify a set of relationships to
automatically populate via an inner join using syntax like this:

    $attr{prefetch} =3D qw/rel1 rel2 rel3/;

CDBI::Sweet automatically figures out which columns to use for the join and
sets up the FROM and WHERE clauses accordingly. I've made a small change
that allows you to specify the type of join you would like:

    $attr{prefetch} =3D ['rel1', {name =3D> 'rel2', type =3D> 'left'}, 'rel=
3'];

The joins are ordered as they will appear in the "FROM" clause, so this
would be:

   FROM me, rel1 left join rel2, rel3

The other small enhancement is that the column returned from the database i=
s
checked for null before being populated. This allows you to use "has_a"
relationships (for example) with null-able keys. If you prefetch using such
a relationship and use a "left" join, you get either "undef" or a reference
to the joined object, depending on whether the column was null or not.

This trivially extends to any other type of join, and essentially gives you
a way to control the "FROM" clause in the same way you can now control the
"WHERE" clause using SQL::Abstract.

I've hacked this in for now, and need to spend some time making it look
nicer, but I'm happy to send a diff to anyone who is curious to see it in
action. I'd love to hear any feedback. It's working for me as-is, but I
could be missing any number of big reasons why it won't work in general. If
you've got one, let me know!

Charles.

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

I sent an email earlier about using "LEFT JOIN" with CDBI::Sweet'=
s prefetch attribute. I've hacked together a version that works for me, and=
 retains backwards compatibility with the existing prefetch attribute. I'd =
like to clean it up and submit it as a patch, but I want to make sure the i=
nterface is reasonable first.
<br><br>Currently, &quot;prefetch&quot; allows you to specify a set of rela=
tionships to automatically populate via an inner join using syntax like thi=
s:<br><br>&nbsp;&nbsp;&nbsp; $attr{prefetch} =3D qw/rel1 rel2 rel3/;<br><br=
>CDBI::Sweet automatically figures out which columns to use for the join an=
d sets up the FROM and WHERE clauses accordingly. I've made a small change =
that allows you to specify the type of join you would like:
<br><br>&nbsp;&nbsp;&nbsp; $attr{prefetch} =3D ['rel1', {name =3D&gt; 'rel2=
', type =3D&gt; 'left'}, 'rel3'];<br><br>The joins are ordered as they will=
 appear in the &quot;FROM&quot; clause, so this would be:<br><br>&nbsp;&nbs=
p; FROM me, rel1 left join rel2, rel3
<br><br>The other small enhancement is that the column returned from the da=
tabase is checked for null before being populated. This allows you to use &=
quot;has_a&quot; relationships (for example) with null-able keys. If you pr=
efetch using such a relationship and use a &quot;left&quot; join, you get e=
ither &quot;undef&quot; or a reference to the joined object, depending on w=
hether the column was null or not.
<br><br>This trivially extends to any other type of join, and essentially g=
ives you a way to control the &quot;FROM&quot; clause in the same way you c=
an now control the &quot;WHERE&quot; clause using SQL::Abstract.<br><br>
I've hacked this in for now, and need to spend some time making it look nic=
er, but I'm happy to send a diff to anyone who is curious to see it in acti=
on. I'd love to hear any feedback. It's working for me as-is, but I could b=
e missing any number of big reasons why it won't work in general. If you've=
 got one, let me know!
<br><br>Charles.<br>

------=_Part_6569_1872237.1139274199789--


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

--===============1585163703==--