On Tue Aug 23 08:59:47 2011, koenc@dalicon.com wrote:
Show quoted text> Hi there,
Hi! (and sorry for the untimely reply)
Show quoted text> according to the documentation we should be able to in the
> Relationship class, use the "where" attribute for filtering
> relationships. I've tried to do that in the latest DBIx::Class
> version (0.08195) and it doesn't work, nor do I see the code
> looking out for that "where" attribute. It results in
> SQL where the filter has not been applied to, so returns
> incorrect results.
>
> This is the definition that I try to do:
>
> __PACKAGE__->has_many(
> "articles_has_article_galleys_pdf",
> "pharmaventures::Storage::Schema::OJS::ArticleGalleys",
> {
> "foreign.article_id" => "self.article_id",
> # "foreign.label" => \"pdf"
> },
> { join_type => 'left',
> where => {
> label => "pdf"
> }
> }
> );
>
> PS: mind the commented line: in an earlier version
> of DBIx::Class I succesfully made a patch that uses
> a string ref as an alternative way of filtering the
> relationship. That code is now harder to reimplement
> in the latest DBIx::Class code alas.
>
You have several unrelated things here, so I will try to deconstruct:
1) A left join with a where clause makes no sense (it will *never* do
what you expect it to do). Consider:
SELECT * FROM artists a LEFT JOIN cds c ON a.id = c.cd_id WHERE c.year =
2000
vs
SELECT * FROM artists a LEFT JOIN cds c ON a.id = c.cd_id AND c.year = 2000
Based on the things you gave above you seem to understand this, so
perhaps the only confusion is that you assumed where will translate to
an ON clause - this is not the case: a where is a where
2) You did not show your invocation, but I suspect the where was
"ignored" during prefetch (not during a search_related call). If this is
the case this looks like a bug duplicate of
https://rt.cpan.org/Ticket/Display.html?id=63709. If this is the case it
is an (obviously) known issue, with an annoyingly involved fix. Due to
the limited utility of the where attr, this bug has not been as of yet
fixed.
3) On your local patch of dbic to use stringrefs - istr you submitting
something similar to the ML which was rejected with a good reason (or
maybe it wasn't you, anyhow). The correct way to do this in recent
versions is through a coderef condition specification as described in
detail here:
http://search.cpan.org/~abraxxa/DBIx-Class-0.08195/lib/DBIx/Class/Relationship/Base.pm#condition
(look for the paragraph "To specify joins which describe more than a
simple equality...")
Let me know your thought on the above points.
Cheers
