FAQ
I'm trying to implement a "Match all values" expression behavior (like
previously discussed as hasAllOfExp or MatchAllValuesExpression on the
mailing list in the past). I'm guessing no one ever implemented a
MatchAllValuesExpression.

However, I'm finding myself inadequate for the task.

For example,

letters
a
b
c

digits
1
2
3


letters__digits
a-1
a-2
a-3
b-2
c-3
c-2


find all 1s: a
find all 2s: a, b, c
find all 3s: a, c

"Match all values" on (1, 2) would generate sql like the following and
return "a"

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

At least, that's my understanding of what would need to be done based
on previous postings.

My actual use case is something along the lines of "any number of
names" + "any number of phones" + "any number of emails" on a contact
record that has a many-to-many relationship with names and with phones
and with emails.

Anyone have any suggestions?

I'm about to give up and do it in-memory by searching for a single
name, and then doing an in-memory removal (from the list) of each
non-matching contact for each remaining name, phone, and email....

Search Discussions

  • Mike Kienenberger at Apr 17, 2006 at 9:56 pm

    On 4/17/06, Mike Kienenberger wrote:
    I'm trying to implement a "Match all values" expression behavior (like
    previously discussed as hasAllOfExp or MatchAllValuesExpression on the
    mailing list in the past). I'm guessing no one ever implemented a
    MatchAllValuesExpression.
    By the way, here's the most relevent threads I found on the subject.

    http://www.objectstyle.org/cayenne/lists/cayenne-devel/2003/09/0096.html
    http://www.objectstyle.org/cayenne/lists/cayenne-devel/2003/10/0005.html
  • Andrus Adamchik at Apr 18, 2006 at 10:14 am

    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.

    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.

    Andrus
  • Mike Kienenberger at Apr 18, 2006 at 3:01 pm

    On 4/18/06, Andrus Adamchik 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupuser @
categoriescayenne
postedApr 17, '06 at 9:54p
activeApr 18, '06 at 3:01p
posts4
users2
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase