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
