Sounds great. The best way to submit patches is via Jira, as everybody
else will see it, not just me. And also there's a "licensed for
inclusion in ASF works" radiobutton that covers us on the legal front.
Andrus
On Mar 6, 2010, at 6:53 PM, Andrew Lindesay wrote:
> Hi Andrus;
>
> Thanks for the reply -- would you like me to change my patch over to
> use ..ize", see if I can understand and patch the
> "Cayenne.readNestedProperty(..)" and then email you an updated patch
> file?
>
> cheers.
>
>>>> * 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
>>> ..ize" 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
>>
>
> ___
> Andrew Lindesay
> www.lindesay.co.nz
>
>
This archive was generated by hypermail 2.0.0 : Sat Mar 06 2010 - 19:08:32 EST