On 4/18/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote: > > On Apr 18, 2006, at 1:53 AM, Mike Kienenberger wrote: > > > select l1.* from letters l1, letters_digits ld1, digits d1, letters > > l2, letters_digits ld1, digits d2 where > > > > d1.value = '1' and ld1.digit_id = d1.digit_id and ld1.letter_id = > > l1.letter_id > > and > > d2.value = '2' and ld2.digit_id = d2.digit_id and ld2.letter_id = > > l2.letter_id > > > The current limitation is due to the fact that Cayenne qualifier > translator removes "duplicate" joins.
Yeah, I noticed that :) And it was mentioned in the previous messages as well. > If you want to take a shot at it and create a patch for the next > major release, you'd have to introduce the "split" expression > semantics as discussed in those messages that you've mentioned. Maybe > use a pipe symbol at a place in the path where a split should start, > like "|r1" or "r1.r2.|r3"?? Second thing to change is > QueryAsembler.dbRelationshipAdded(..) method that removes > "duplicates" to support the splits. > > There are a few more things to take care of to fully support splits, > so this is certainly not a trivial change. > > I guess even if for now you stick with an in-memory solution or a > SQLTemplate, the issue is worth putting on the "AFTER 1.2" Road Map. I'll go ahead and do that. I don't really have time to deal with trying to implement a "working" solution at present, and while I'd like to be able to use the functionality later, my current use case is a one-time data conversion. Most of the time, I will have one name, one phone, and one email, so perhaps an initial query on the first item in each list (so there's no duplication removed) followed by an in-memory cleanup would be easiest. I was thinking about how to do it with an SQL template last night, but it seems like a bit of work.
