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

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

Federico Heinz <fh...@vi...> wrote:
> On Thu, 2003-09-25 at 16:36, Sebastien Bigaret wrote:
> > The XML-models or the PyModels are Entity-Relationship models, they do
> > represent how classes map to databases. They are more database-centered
> > than UML-centered, that's why, in such situations, the E-R diagram will
> > differ from the class diagram.
>=20
> Right. What I meant is that the XML constructs a flat view of the tables
> making up the object.

Indeed.

> >   BTW: there is a reason why models requires properties to be copied: a
> >   string attribute in a parent can have a width of 40, while a child can
> >   ask a width of 50 for the same field.
>=20
> I got that from the docs... not sure about how good this may be for the
> app. Of course, when each class maps to a different table this is
> probably needed, particularly if it's a legacy database...

That was the exact reason why this was made possible!

[my silly comment snipped]
> I sent an example earlier. I understand that what happens is that all
> Vertebrate fields live in the Vertebrates table, and the Mammals table
> contains just the non-inherited fields. However, a select on Mammals
> will also return inherited fields as if they were there.
> This is my understanding of what is going on... I haven't looked at the
> innards of PostgreSQL to find out.

Dunno either how postgresql achieves this. BTW and just in case, this
may be the place to recall that the framework automatically and
transparently handles fetching objects on an inheritance tree, whatever
the underlying db schema.

(this is the 'isDeep' parameter of fetch(), see
 http://modeling.sf.net/UserGuide/ec-fetch-inheritance.html)

> >   About unique IDs: the framework takes care of assigning a unique ID (=
per
> >   inheritance tree) to any object, regardless of where they are
> >   stored. So, if you create two objects v1(Vertebrate) and m1(Mammal),
> >   with Mammal inheriting from Vertebrate, it is guaranteed that
> >   v1.ID!=3Dm1.ID, always --even in horizontal mapping.
>=20
> So we don't use the automatic unique id generator in the DBMS... Doesn't
> this break horribly in a multiple-address-space scenario?

Not at all! For postgresql e.g., we use dedicated sequences, one for
each inheritance tree; when generating the db-schema, you'll see this:

    [...]
    CREATE SEQUENCE PK_SEQ_BOOK START 1
    CREATE SEQUENCE PK_SEQ_WRITER START 1
    [...]

All sequences names PK_SEQ_... are used by the pk generation mechanism.

MySQL does not support sequences so we use a different mechanism (a
dedicated table containing only one row, plus specific SQL statements to
safely increment the next PK value).

In any case, it is a strong requirement for the framework's pk-
generation process to be safe in multi-threaded (same adress space) or
in multi-processes (different address spaces) environments.

[...]
> > Be also
> > aware that, while pg accepts multiple inheritance, the framework does
> > not support more than one parent for a given entity.
>=20
> Multiple inheritance is an abomination :-)

I'm glad you said it!

> > BTW, if you can disclose, I'll be really interested in hearing the
> > reasons why you want vertical mapping  --esp. against the additional
> > overhead each fetch (where tables should be JOINed), and each
> > insert/update (where two INSERT/UPDATES are needed).
>=20
> Well, there were two important problems without vertical mapping:
>       * unique ids for sibling classes is a bitch of a problem when you
>         have multiple address spaces

As stated above, the framework does take care of this.

>       * we often have relations that are "to instances of any subclass
>         of foo", which are pretty easy to implement in vertical mapping,
>         but were near to impossible in the framework we're trying to
>         break from.
> As a matter of fact, I look forward to finding out how you solved the
> second problem in Modeling...

Well, since the siblings get different ids, resolving FKs "simply" means
deep-fetching the inheritance tree to find the related row. So, when an
object has a relationship pointing to an entity, it can actually refer
to this entity or any of its sub-entities --with nothing more than a
classic foreign key.  And of course, this is why the framework takes
great care of assigning a different id to the siblings.

  If you're interested in looking at the code, the methods responsible
  for this are:

    - for to-one relationships:
          AccessFaultHandler.completeInitializationOfObject()
          [in module FaultHandler]
=20=20=20=20
    - for to-many relationships:
          DatabaseContext.objectsForSourceGlobalID()
          [in module DatabaseContext]
      triggered by:
          AccessArrayFaultHandler.completeInitializationOfObject()
          [in module FaultHandler]

  And last, willRead() in DatabaseObject (superclass for CustomObject)
  is the one responsible for asking the fault handler to complete the
  initialization of the object.


    Will this allow a second look at horizontal mapping ? ;)

-- S=E9bastien.