Re: Small Patch

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Sat Mar 06 2010 - 19:08:05 EST

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

    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