cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: split expressions
Date Fri, 29 Jan 2010 10:50:20 GMT
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.


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

View raw message