Re: split expressions

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri Jan 29 2010 - 05:50:20 EST

  • Next message: Lachlan Deck: "Re: split expressions"

    Sorry, there's too many things going on in Cayenne right now. This one
    is a very important discussion, but I guess I have to drop the ball on
    it for now. We'll definitely get back to it, but I suggest we don't
    jira anything yet, as the plan is not yet clear, and too-high level
    Jiras are not very helpful.

    Andrus

    On Jan 29, 2010, at 3:55 AM, Lachlan Deck wrote:

    > Hi Andrus,
    >
    > just following this up again. Just a few questions:
    > a) is it also worth also thinking about the ability to specify the
    > join-type in the model for a relationship in order to specify what's
    > the default?
    > b) is there any further discussion needed to identify necessary jira
    > tasks?
    >
    >
    > On 15/01/2010, at 10:51 PM, Andrus Adamchik wrote:
    >
    >>
    >> On Jan 15, 2010, at 11:05 AM, Andrus Adamchik wrote:
    >>
    >>> * ASTs are generic and not very intuitive for direct manipulation
    >>> in API. A good analogy would be DOM trees vs. real object models
    >>> represented by those trees.
    >>>
    >>> * ASTs often have slight differences in structure compared to an
    >>> ideal domain object. This is more pronounced in EJBQL, that has
    >>> AST's for SelectClause and other irrelevant nodes on the tree
    >>> (irrelevant to the user of course)
    >>>
    >>> * Due to the use of JavaCC as a parser, we have this odd looking
    >>> method names inherited from the parser Node class (e.g.
    >>> org.apache.cayenne.ejbql.parser.Node)
    >>
    >>
    >> Answering my own question (I hope)... I don't remember all the
    >> history by now, but actually this might be the case when we went
    >> along with the framework-provided convenience, ignoring its
    >> downsides. We are using JJTree syntax - a JavaCC preprocessor that
    >> allows to build ASTs "out of the box". I think if we take a step
    >> back and use straight JavaCC, we can create arbitrary domain
    >> objects at the expense of extra code and reduced parser clarity. Or
    >> we can keep using JJTree and do a postprocess conversion of AST to
    >> domain object, at the expense of performance (similar to SAX vs.
    >> DOM choice I guess).
    >>
    >> In any event we need to experiment modeling EJBQL (and potentially
    >> Expressions) as "AST-free" domain objects and see how that works,
    >> before rewriting the parsers.
    >>
    >> Andrus
    >
    > with regards,
    > --
    >
    > Lachlan Deck
    >
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Fri Jan 29 2010 - 05:50:59 EST