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
This archive was generated by hypermail 2.0.0 : Fri Jan 29 2010 - 06:11:34 EST