On 29/01/2010, at 9:50 PM, Andrus Adamchik wrote: > 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,
That's what I thought. I was just going through our tasks and seeing where this was up to. > and too-high level Jiras are not very helpful. Sure. Thanks. > 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 >> >> >> >> > with regards, -- Lachlan Deck
