Re: entities with calculated fields

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Feb 20 2007 - 06:49:49 EST

  • Next message: Andrus Adamchik: "Re: Model many to many"

    > Would you like me to create a task that we mark the API and
    > documentation mentions of it as deprecated?

    Yeah - IMO now is a good time to mark it as deprecated.

    As to the replacement, this is not a simple question and it goes to
    the ORM basics, namely - only straight table rows joined via PK/FK
    keys can be mapped to an object graph in a clean fashion. If a result
    row's identity is unclear (e.g. a few table rows aggregated in some
    derived data rows), ORM model breaks. In Cayenne we recognize that by
    separating *objects* managed by Cayenne runtime, and *data rows*
    representing some tabular data that may or may not have a direct
    relationship to an object with a given identity. Data rows can be
    fetched, but they are unmanaged.

    What we can do to improve the usability of the data rows is to
    produce "unmanaged" objects of a specific class from tabular data
    (IIRC JPA spec SqlResultSetMapping should help us with that). For now
    you can use data rows in your app, or wrap them in some unmapped user
    defined classes to add behavior.

    A few side notes:

    * "data rows" are billed as a performance optimization feature in the
    User Guide, but more importantly, this is a representation of tabular
    data. We may need to make it more clear in the docs.

    * The EOF example (which IIRC you can map in Cayenne already), is
    only addressing an edge case of derived data that doesn't change the
    identity of the row, so I don't think you can do a relationship count
    as a EOF derived column.

    Andrus

    On Feb 20, 2007, at 2:21 PM, Aristedes Maniatis wrote:
    > On 20/02/2007, at 1:43 AM, Andrus Adamchik wrote:
    >
    >>> I think Andrus is the right person to answer your question, but I do
    >>> recall a conversation where the intention was for derived dbentities
    >>> to be removed.
    >>
    >> True - that was an ugly and limited workaround. We do need to get
    >> rid of it.
    >
    > Would you like me to create a task that we mark the API and
    > documentation mentions of it as deprecated? Would a goal be to
    > replace this with something like:
    >
    > http://developer.apple.com/documentation/LegacyTechnologies/
    > WebObjects/WebObjects_4.5/System/Documentation/Developer/
    > EnterpriseObjects/EOTools/DerivedProperties1.html
    >
    > or do you think that SQLtemplates are the catch all for this?
    >
    >>> SQLTemplate can also work with data objects, just need to make sure
    >>> the object properties match the returned column names. The SQL
    >>> template has a nice facility to support multiple database
    >>> versions as
    >>> well.
    >>
    >> Yep, that would be my recommendation as well.
    >
    >
    > I've read the docs but I don't quite understand how this mapping
    > back to an object entity will work. If I use the #result notation
    > to specify all the attributes already in the _Artist.class and I
    > then add something like paintingCount to Artist.class, how do I
    > then tell the SQLtemplate to return that derived attribute into
    > paintingCount?
    >
    > #result('COUNT(SELECT ...)' 'int' paintingCount)
    >
    > Will that do it? Is the columnAlias mapped to the attribute in the
    > object entity?
    >
    >
    > Ari
    >
    >
    >
    > -------------------------->
    > ish
    > http://www.ish.com.au
    > Level 1, 30 Wilson Street Newtown 2042 Australia
    > phone +61 2 9550 5001 fax +61 2 9550 4001
    > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
    >
    >



    This archive was generated by hypermail 2.0.0 : Tue Feb 20 2007 - 06:50:53 EST