ObjAttribute mapping

From: Andrei Adamchik (aadamchi..obox.com)
Date: Mon Jan 21 2002 - 19:37:06 EST

  • Next message: Andrei Adamchik: "development notes"

    Per our phone conversation with Misha, here is a description of the design
    changes I am about to make:

    Current relationship of ObjAttribute -> DbAttribute is a "to-one" approach.
    It means that ObjAttribute will *always* map to a single table column. I
    want to change that.

    Instead, internally, each ObjAttribute would map to a
    org.objectstyle.cayenne.exp.Expression. In a simple case (table column),
    expression type would be DB_NAME (does not exist yet, see DB_PATH). But it
    can also be expression of type COUNT, AVG, MAX (aggregates are not defined
    yet, I will add them soon), ADD, SUBTRACT and many more. This means that we
    can represent almost any real life mapping scenario without SQL hardcoding.

    So, API for ObjAttribute will change like that:
    1. "DbAttribute getDbAttribute()" and "setDbAttribute(DbAttribute)" will be
    removed.
    2. "Expression getMappingExp()" and "void setMappingExp(Expression)" will
    be added.

    Having said that, I suggest that for the initial release we DO NOT
    implement any visible "weird" mapping support in the tools (but still
    having options to do it via API). Instead this will be used from query
    package. SelectQuery should allow to define any kind of result attributes
    based on root entity, even things that are not defined in the root
    ObjEntity. Of course in such cases mapping will not be done to a predefined
    DataObject subclass. Rather to a list of some sort of generic objects or
    something like HashMaps will be returned on select.

    This morning on the plane I developed this approach on paper and played
    with different scenarios/implications. It turns out to be very flexible and
    allows OO-style for SELECT queries of almost any type - with GROUP
    BY/HAVING, UNIONS, etc. I will be working on the new API this week. I have
    a design in place, so it should be pretty straightforward to implement.

    Sorry for the long message.

    Andrei



    This archive was generated by hypermail 2.0.0 : Mon Jan 21 2002 - 19:36:53 EST