Re: [Modeling-users] Re: Implementing inheritance through vertical mapping

[Sebastien B. <sbi...@us...>]

        Hi,

  Sorry that I announced the plan for earlier, but I couldn't find the
  time for it. Looks like I never learn from those time constraints :/

> > because I considered a bit slower than horizontal: with 'nb' classes and
> > subclasses, [...] I never tried it --but my opinion has no real
> > weight here, remember I'm really not good at sql: that was one of the
> > motivation for writing the code :)
>=20
> Doh! And I was looking up at you for enlightenment! :-)

  Yeah, well, you know, if I was a SQL guru I probably wouldn't have
  need the framework so badly ;)

Okay, back to it: here is the 1st draft of a plan to support vertical
mapping.

Prerequisite (at least for me:)
------------

  * define a sample model, one root entity A, two sub-entities B and
    C, and at least one sub-entity D for B (we need a sub-sub-entity to
    make sure that the support for vertical mapping will support an
    inheritance tree of any depth). Given this sample model, define:

    - the derived db-schema,

    - SQL statements for selecting, inserting, updating and deleting all
      those 4 entities.

    Note: we cannot simply reuse as-is one of the test models
          AuthorBooks or StoreEmployees, since they involve only one
          level of inheritance, at most.

Code
----

This is what come to my mind by now. We need to:

  * have PyModels (and xml, but we can start w/o xml) support flattened
    attributes and relationships. A flattened property is basically a
    path/dotted notation, such as 'toPerson.name' (stored in an
    attribute 'definition' of Attribute and Relationship). In the core,
    both Attribute and FlattenedRelationship are almost ready to store
    this in models at runtime (I say almost, because it's never been
    used so it is possible that bugs remain in them) --see methods
    isFlattened(), definition(). I've a look at them and it seems that
    the xml support is already almost (if not fully) done.

       ...Re-reading this, I realize that these 2 classes need to be
       refactored. The framework will need to know flattened attributes' and
       relationships' properties from the parent (such as a string's
       width, a relationship's cardinality, etc.), and this is not
       supported at all. That's not that bad, both classes need a bit of
       refactor anyway (yes, they'ere rather old, and pretty ugly if you
       look at their code).

    BTW this is how /I/ think the model would be designed:

      - define root entity A,

      - define sub-entity B w/ parent=3DA,

      - in sub-entity B, define a to-one rel. 'toA' to the parent; this
        relationship will join B's PK to A's PK (and will probably not
        be a class property),

      - in sub-entity B, flatten every properties of A
        (def.=3D'toA.<attrName>' or 'toA.<relName>')

    --> this is for a single level of inheritance. Now it's not clear to
        me at all how this should be done when 2+ levels of inheritance
        are involved. Should a sub-entity flatten properties from its
        direct parent only, or should it flatten its parents
        non-flattened properties, then its parent's parent non-flattened
        properties, etc. ? That will probably be clearer when we'll have
        examples on how this is best done at the SQL level.

    We also need to make sure that defining a PyModel w/ vertical
    mapping will be painless. That must not be that difficult, in fact
    it should be sufficient to i. detect that a sub-entity has a
    different externalName() (db-table's name) than its parent,
    ii. automatically append the necessary items in the sub-entity
    (toOne rel. to parent, flattened properties).

  * Have SQLExpression.py detect and generate SQL statements for
    vertical mapping. This is the biggest part of it, in fact, and
    probably not the most trivial --the main problem is in fact that
    SQLExpression's internals are not very well documented, I've a few
    notes on paper that I should probably put somewhere. I don't not
    have them at hand though, still need to look for them --or rewrite
    them.

  * Write tests for selects, inserts, updates and deletes,

  * Release the code!


-- S=E9bastien.