Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <FD809F7C-55A8-4A41-87CC-50B7DA0E06BA@objectstyle.org>
From: Andrus Adamchik <andrus@objectstyle.org>
To: dev@cayenne.apache.org
In-Reply-To: <4B8B0B2D-DD30-4686-9429-0D0158A27609@lindesay.co.nz>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Small Patch
Date: Sat, 6 Mar 2010 17:56:17 -0500
References: <D14C617F-8D81-401D-B0DB-870BCC8F508D@lindesay.co.nz>
 <87316BB4-FAC1-4997-BDD8-3E755D991A33@objectstyle.org>
 <4B8B0B2D-DD30-4686-9429-0D0158A27609@lindesay.co.nz>


On Mar 4, 2010, at 2:50 PM, Andrew Lindesay wrote:

>>
>> * This type of key-value coding creates property naming conflicts.  
>> EJBQL (see above) solves that by treating "size" as a function, not  
>> a property. If I am not mistaken WO would use something like @count  
>> to disambiguate naming, no?
>
> WebObjects does support "@count", but also "count".  I guess "@size"  
> gets around the naming conflict of entity attributes so maybe that  
> is a better way to go.  I think that would be a valid approach.  Too  
> much functionality in such nested properties rather than controller  
> classes I think is not the way I would go, but this is so frequently  
> used that it is worth it.  I guess "size(...)" function would work,  
> but I think I prefer "@size" on the end of the nested property and  
> to not create a system of using functions.

+1.


>> * To be consistent it would be nice to make it work in expressions  
>> across the board, i.e. not only for in-memory evaluation, but also  
>> for SelectQuery qualifiers
>
> That would be useful, but not really necessary straight away.
>
>> (EJBQL query supports that already, although with a different  
>> syntax: SIZE(author.books)).
>
> Sorry I don't know too much about EJBQL at this stage so I will have  
> to let you make a call on that.

Yeah, I just wanted to outline what else needs to be done for this to  
become a first class citizen in Cayenne. One other thing I forgot is  
Expression.fromString(..) parsing. Anyways that can be added later.


> Another thing which may help me implement this for my own use is if  
> the "readNestedProperty(..)" method were to iteratively be applied  
> to DataObjects rather than to eventually hit  
> Cayenne.readNestedProperty(..) and iterate in there.  The entire  
> nested property is currently parsed at the start, but if it iterated  
> through the "readNestedProperty(..)" methods of the data objects  
> then just the first part of the nested property could be 'parsed  
> off'.  The number of strings created from parsing the nested  
> property would only be 2x the number compared to the current  
> implementation.


+1. o.a.c.Cayenne class can call DataObject's implementation  
internally (instead of doing it the other way), and if the root object  
is not a DataObject, call generic  
o.a.c.reflect.PropertyUtils.getProperty

Andrus