Re: RFC: semantic of expressions

From: Giulio Cesare Solaroli (slrgcs..bn-italy.com)
Date: Tue Oct 21 2003 - 12:25:46 EDT

  • Next message: Andrus Adamchik: "Re: RFC: semantic of expressions"

    On Tuesday, Oct 21, 2003, at 18:04 Europe/Rome, Andrus Adamchik wrote:

    > Hi Giulio Cesare,
    >
    > On Tuesday, October 21, 2003, at 04:28 AM, Giulio Cesare Solaroli
    > wrote:
    >>
    >> Item <-->> Bid <<--> User
    >>
    >> In this scenario, you could be interested in defining many
    >> expressions; some examples:
    >>
    >> 2- "all items that have bids done by User whose gender is "male" and
    >> whose address is in the United States.
    >
    >
    >> Second take:
    >> users = new Vector();
    >> users.add(User_A);
    >> users.add(User_B);
    >> expression = new MatchAllValuesExpression("to_bids.to_user", users);
    >> query = new SelectQuery(Item.class, expression);
    >> result = dataContext.performQuery(query);
    >
    > I am more in favor of the second version too. One question though -
    > how are you planning to express the "splits" that you have in the
    > Objective C version? Maybe have another KeyValue expression containing
    > the "no split" part, and taking MatchAllValuesExpression as its
    > "value"? Is this what you have in mind?

    The way we are using it now with EOF is that MatchAllValuesExpression
    splits the relationships at the first to-many relationship; this
    usually match with the desired behaviour.

    When a different behaviour is required, it could be possibile to call a
    method like this:

    expression = new MatchAllValuesExpression("to_bids.to_user.to_frinds",
    users);
    expression.dontSplitUpTo("to_bids.to_user");

    In this way I could look for items with bids done by persons that have
    UserA and UserB as friends.

    > Another related topic. We were planning to allow expressions encoded
    > as strings (e.g. "xyz.abc = ..and mnk != %@", you see what I am
    > talking about). I wonder how we can express the case above (and more
    > complex ones with splits) in this format as well? Add an operator for
    > "match all" or something? (SQL has "ALL" operator, maybe use it too?)

    Excellent question; I was forgetting about this topic altogether, as we
    never use it in EOF as it was missing a fundamental feature: being able
    to extend the string analyzer, in order to be able to create newly
    coded Expressions within the same procedure.

    What I would have like to have in EOF was a way to be able to tell the
    framework that the syntax "xyz.abc = (80, 30, 4)" should have create an
    instance of MatchAllValuesQualifier.

    Besides what the final syntax will look like, I will like to sort out a
    way to have a collaborative process (between all defined subclass of
    Expression) to transform strings in Expressions, thus allowing newly
    created Expression subclass to have the option of joining the
    translation process.

    No idea on how to implement this, yet, but I will try to think on how
    to include it in the code I am writing.

    >> select t0.id_item, t0....
    >> from item t0, bid t1, bid t2, user t3, user t4
    >> where t0.id_item = t1.id_item
    >> and t1.id_user = t3.id_user
    >> and t3.id_user = <id User_A>
    >> and t0.id_item = t2.id_item
    >> and t2.id_user = t3.id_user
    >> and t3.id_user = <id User_B>
    >
    > BTW, the last join in the chain can be omitted when matching on PK,
    > optimizing this query a little bit (I believe Cayenne already
    > implements "no last join" policy):
    >
    > select t0.id_item, t0....
    > from item t0, bid t1, bid t2
    > where t0.id_item = t1.id_item
    > and t1.id_user = <id User_A>
    > and t0.id_item = t2.id_item
    > and t2.id_user = <id User_B>

    Usually this is not a bid deal, as the RDMS itself should optimize the
    query and ignore the further join.
    Anyway you are perfectly right, and I will try to take also of this
    kind of optimization in the new package.

    Giulio Cesare



    This archive was generated by hypermail 2.0.0 : Tue Oct 21 2003 - 12:25:57 EDT