[Dbix-class] modifying join condition in search

Richard Robinson catalyst at beulah.qualmograph.org.uk
Wed Jul 25 15:19:43 GMT 2007


On Thu, Jul 19, 2007 at 06:01:38PM +0100, Pedro Melo wrote:
> On Jul 19, 2007, at 11:55 AM, Jon Schutz wrote:
> 
> No I want the first case. The watchers table has a row for each user/
> topic that is being watched.
> 
> I want to know, for all topics in my query which ones are being watched.
> 
> >In answer to the original question, I believe the parameter '5'  could be
> >passed through as a bind variable; see
> >
> >http://search.cpan.org/~mstrout/DBIx-
> >Class-0.08003/lib/DBIx/Class/Manual/
> >Cookbook.pod#Arbitrary_SQL_through_a_custom_ResultSource
> 
> hmms.. I'll have to experiment.
> 
> Thanks for the tip.

And likewise, thanks. Slow followup, because I've been playing with it; and,
yes, it does what I was just groping to realise I needed to do. Nice. For
added flexibility, put it into a function and you can use the args to build
the sql (following on from which, it would be elegant if table/field names
could also be bound, but this doesn't seem likely. A brief note in perldoc
DBI that it might be possible in some non-standard backend-dependent way. Oh
well).


Picking up the 'naive user reading the manual' hat briefly, is there any way
to see that such a trick is possible, in the absence of a Cookbook recipe ?
In fact, having seen that it is, how to understand it ?  I can't find where
'name()' is documented. It looks as though it's a member of ResultSource ?
'name' is not a good word to rgrep for ... singlestepping into it doesn't
leave me much the wiser, either.  What goes on ?

I probably ought to just accept it as voodoo and get on with writing
something Useful, but in the long run it might be handy to learn how to work
such things out.


-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem




More information about the Dbix-class mailing list