Re: entities with calculated fields

From: Aristedes Maniatis (ar..sh.com.au)
Date: Tue Feb 20 2007 - 09:33:23 EST

  • Next message: Kevin Menard: "RE: JIRA Web Services"

    On 20/02/2007, at 10:49 PM, Andrus Adamchik wrote:

    > 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.

    Moving to dev...

    Derived attributes don't need to break the object graph. They would
    be read only since it makes no sense to write that data back to the
    database, but they could cleanly map SQL query results to an object
    entity attribute. Mostly I'm thinking of aggregate functions across a
    relation (SUM, COUNT, MAX, etc) but anything would be possible
    including a flattened attribute (where a field from a related table
    is added to the many table attributes - this might be easier to deal
    with in some situations) or more exotic SQL functions like CHECKSUM
    or SOUNDEX.

    Sometimes it might be necessary to use in-database functions rather
    than adding this in Java to the object entity sub-class. In my case,
    mainly for speed, but I can imagine other uses too.

    Derived entities are another situation again. They need to be
    completely read-only since you can never map them back to database
    rows. But as you say, data rows are a good solution to this and the
    SQLtemplate mechanism is very flexible. To be honest I don't quite
    understand the need for derived entities with grouping (is this for
    report writing?) but should they stay if they promised to be read-
    only? My interest in them was because I thought they were a way to
    create derived attributes.

    I'm still not clear about the SQLtemplate. Is it the columnAlias
    which defines how an attribute is mapped to the object entity? How
    does this work today if we want objects back out and not just data rows?

    Ari Maniatis

    -------------------------->
    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 - 09:34:23 EST