cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachlan Deck <lachlan.d...@gmail.com>
Subject Re: split expressions
Date Fri, 29 Jan 2010 01:55:29 GMT
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




Mime
View raw message