On Sun, 26 Oct 2008, Noel Burton-Krahn wrote:
Can you rephrase this second issue you are talking about, without
referring the the first one (which is ENOPROBLEM).
If you construct a sufficiently complex select_related clause, DBIx
will construct ambiguous SQL. Take a look at the SQL that DBIx
generates: It does not uniquely qualify the selected columns. Here
was the SQL that failed, which you'll see if you run my test in my
patch:
SELECT artist_undirected_maps.id1, artist_undirected_maps.id2
FROM artist_undirected_map me
LEFT JOIN artist mapped_artists ON (
mapped_artists.artistid = me.id1 ) OR ( mapped_artists.artistid =
me.id2 )
LEFT JOIN artist_undirected_map artist_undirected_maps ON (
artist_undirected_maps.id1 = mapped_artists.artistid ) OR (
artist_undirected_maps.id2 = mapped_artists.artistid )
WHERE ( ( id1 = ? ) OR ( id2 = ? ) )
The id1 and id2 in the "where" clause should have been uniquely
qualified like me.id1 and me.id2.
Mind posting a DBIC statement that produces this sort of SQL? I'm failing
to discoevr which part of the patch that was.
Thanks,
Jess
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
