On 4/18/06, Andrus Adamchik <andru..bjectstyle.org> 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.
This archive was generated by hypermail 2.0.0 : Tue Apr 18 2006 - 11:00:53 EDT