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
