Re: Small Patch

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Sat Mar 06 2010 - 17:56:17 EST

  • Next message: Andrew Lindesay: "Re: Small Patch"

    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