Very cool. +1 for this (and the changes you checked in yesterday). One
comment on (8):
> If the matching record in the referred
> table does not exist such a SELECT query will not return the
> corresponding
> record in the master table in the result set which is considered to be
> correct behavior (!!?).
... until we implement outer join supportfor DbRelationships.
Andrus
Andriy Shapochka wrote:
> I have compiled a more or less strict definition of the new proposed
> ObjAttribute mapping based on our previous discussions. Please see the
> attachment. It is more general than what was proposed earlier so the
> spec will cover DataObject inheritance and compound ObjEntities, and
> many kinds of "to-one" lookups. The next step will be to introduce the
> same concept for ObjRelationships and thus expand the notion of
> flattened relationships.
> Any comments?
> Thanks.
> Andriy.
>
>
> ------------------------------------------------------------------------
>
> ObjAttribute Mapping Specification.
>
> This document describes new principles of mapping ObjAttributes
> to DbAttributes and related operations on DataObjects.
>
> 1) Each ObjAttribute in an ObjEntity is mapped to a DB_PATH
> comprised of 0..n DbRelationships and 1 DbAttribute.
>
> 2) If there are 0 DbRelationships in the DB_PATH
> DbAttribute must belong to the DbEntity "MasterTable"
> this ObjEntity refers to (defined by the attribute
> dbEntityName in element obj-entity, see data-map.dtd).
>
> 3) If there are 1..n DbRelationships ("r_1",.."r_i",.."r_n")in the DB_PATH
> the following rules apply:
> a) Each "r_i" is "to-one" DbRelationship defined in this DataMap.
> b) "r_1" originates from "MasterTable".
> c) Target DbEntity of each "r_i" coincides with Source of "r_i+1".
> d) DbAttribute belongs to the target DbEntity of "r_n".
>
> 4) The element obj-attribute in data-map.dtd will be modified
> to support the mapping. Namely:
>
> <!ATTLIST obj-attribute
> name CDATA #REQUIRED
> db-attribute-path CDATA #REQUIRED
> type CDATA #REQUIRED
>
>
> Where the attribute db-attribute-path will accept values like:
> DB_ATTR_NAME - name of one of the DbAttributes belonging to "MasterTable".
> dbRelationshipName1.DB_ATTR_NAME,
> dbRelationshipName1.dbRelationshipName2.dbRelationshipName3.DB_ATTR_NAME,
> etc.
>
> 5) An ObjEntity is allowed to be "read-write" only if for each of
> its ObjAttributes one of the following statements is true:
> a) ObjAttribute is mapped to a DbAttribute of the DbEntity
> this ObjEntity refers to (defined by attribute dbEntityName in
> element obj-entity, see data-map.dtd).
>
> b) ObjAttribute is mapped to a dbRelationship1.dbAttribute
> where dbRelationship1 is a "one-to-one" DbRelationship with
> the target column defined as the primary key of the target
> DbEntity. That is, if DbEntity of this ObjEntity is a master
> table and target DbEntity is a dependent table for which
> the primary key is exactly that of the master table.
>
> 6) For the sake of simplicity any ObjEntity that does not satisfy 5)
> must be "read-only" until and if, someday, "read-only" ObjAttributes
> are introduced and allow fine-grained tuning.
>
> 7) Specifics of the operations INSERT, DELETE, UPDATE for DataObjects
> defined by ObjEntities having ObjAttributes that comply with 5.b):
> INSERT) New record is inserted into the dependent table along with
> the one inserted into the master table. Its primary key value is
> the same as the primary key value for the master table record.
> DELETE) The matching record is deleted from the dependent table
> along with the record in the master table.
> UPDATE) Values of the corresponding ObjAttributes are used to update
> the matching record in the dependent table when the record in the
> master table is updated.
>
> 8) Specifics of SELECT for "read-write" and "read-only" ObjEntities:
> DbRelationships indicated in the DB_PATH provide the sufficient information
> to construct additional inner joins to retrieve the attribute
> values from the referred tables. If the matching record in the referred
> table does not exist such a SELECT query will not return the corresponding
> record in the master table in the result set which is considered to be
> correct behavior (!!?).
>
>
>
This archive was generated by hypermail 2.0.0 : Mon Mar 03 2003 - 20:40:47 EST