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 "@size", 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 @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
___
Andrew Lindesay
www.lindesay.co.nz
