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
