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..ount
>> to disambiguate naming, no?
>
> WebObjects does support ..ount", 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 ..ize" 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
This archive was generated by hypermail 2.0.0 : Sat Mar 06 2010 - 17:56:49 EST