cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Small Patch
Date Sat, 06 Mar 2010 22:56:17 GMT

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


Mime
View raw message