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
