Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (nike.apache.org: domain of lachlan.deck@gmail.com
 designates 74.125.78.145 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=k57Z0ziKBsYcRfIM+NfSkFIQfw6tFRP6nDz4+qufs/pvXsSfH2+XmDXOo2R+8QtIz5
         IZCNDx4w5pxs9SlkJjldO76Dy2HNnYoxxlQRpIxE43adQ9bOPAIaWRVImp0Bzr4Ew96G
         QRw2PfGakOSGcoZiEpxDCzKOdQhZMUnLSxGqo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: split expressions
From: Lachlan Deck <lachlan.deck@gmail.com>
In-Reply-To: <DBB7844E-EEBB-4DFC-92DF-0DDB16AC0ED1@objectstyle.org>
Date: Fri, 29 Jan 2010 12:55:29 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B1E26F9-6201-417F-9F88-B6492DC8D7D3@gmail.com>
References: <EF9002DE-F99B-41DA-B782-BD22FC521417@gmail.com>
 <7C9958A1-DED5-4B03-8015-FCF8F75EAF9A@objectstyle.org>
 <4B4D90B3.6080106@maniatis.org>
 <24443385-F9ED-4C91-9C1F-8D8C4C162432@objectstyle.org>
 <4B4DA436.40808@maniatis.org>
 <A930907B-7D84-4812-82DB-632052C4C62E@objectstyle.org>
 <BDAA04BD-104C-4DC8-849A-5765F2A04265@objectstyle.org>
 <4B4DBECB.3070300@maniatis.org>
 <490F4342-2E90-44ED-9A1C-2BE036599826@objectstyle.org>
 <4B4EE6A8.3040300@maniatis.org>
 <72724C82-DC8F-4E62-8DEB-2A886C0F2576@objectstyle.org>
 <DBB7844E-EEBB-4DFC-92DF-0DDB16AC0ED1@objectstyle.org>
To: dev@cayenne.apache.org

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:

>=20
> On Jan 15, 2010, at 11:05 AM, Andrus Adamchik wrote:
>=20
>> * 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.
>>=20
>> * 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)
>>=20
>> * 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)
>=20
>=20
> 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).
>=20
> 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.
>=20
> Andrus

with regards,
--

Lachlan Deck