On Fri, Feb 22, 2013 at 11:23:50AM +0000, Will Crawford wrote:
> It would probably be more intuitive to return something like:
>
> {
> element => {
> concept => { concept_id => nnn, foldername => 'xxx' },
> ...
> },
> ...
> }
>
> ?
At first glance yes. The problem here is that you are incorrectly
assuming that given 'concept.concept_id' one can simply infer we are
talking about the 'concept' from join => { element => 'concept' }.
However the moment *another* 'concept' appears, possibly due to chaining
somewhere deep in your app - what do you do? Here is a real test case: [1]
Bottom line - heuristics at this level is undesireable, however a
sugar-providing ResultSet role to pre-munge the search attributes living
outside of DBIx::Class is free to try this.
[1]
http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=dbsrgits/DBIx-Class.git;a=blob;f=t/prefetch/diamond.t#l23
_______________________________________________
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/dbix-class@lists.scsys.co.uk
