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

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

Federico Heinz <fh...@vi...> wrote:
> On Thu, 2003-09-25 at 10:37, Sebastien Bigaret wrote:
> > I can't remember if it's been discussed here, however this is the way
> > I think this could be done:
> >  - models: add support for flattened attributes and
> >    relationships. Flattened properties are exactly this: take the value
> >    for a given field from another entity (hence potentially from another
> >    table). Flattened properties will be declared with a simple path,
> >    such as: toEmployee.toStore.name
> >    (BTW, backward-compatibility should, and will, be ensured)
>=20
> OK, so what we're talking about here is that the XML is a description of
> the *classes*, and how they map to the database, not a description of
> the database itself (i.e. "entities" declared in the XML are "class"
> entities, not "table" entities). No problem with that, I'm just trying
> to make sure we're talking about the same things.=20

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.

>In this way of
> handling things, the XML will never reflect inheritance, and all classes
> that are part of an inheritance hierarchy will have to specify the
> flattening of each attribute.

The XML will not directly reflect the class diagram, at least not in the
same way than UML models, however:

- the inheritance tree is modeled by the 'parent' field in Entity,

- each subclass will have their own entity and table, and these
  sub-entities will have flattened attributes and relationships pointing
  to the superclass'. Here you're right, the inherited attributes and
  relationships should be flattened (in the xml) from the parent to the
  children --but this is also the case for horizontal mapping (where
  each class gets its own table): although in this case there is no
  flattened properties, the real attributes and relationships are also
  copied.

> This makes writing the XML by hand a major
> pain in the neck, though it probably doesn't matter (at least to us,
> we're planning on generating this XML from our own, richer XML dstabase
> schema description).

XML-models have no default value, in fact they are a comprehensive
description of the models, so in general designing them by hand is a
pain --that's why the ZModeler was written, and also why PyModels are a
great win :) Note that in PyModels, properties do not need to be copied
from parent to children, this is done automatically.

  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. Since model introspection is
  something the framework does a lot, we do not want to compute
  inherited attributes if they are not overriden: that's why they are
  copied. And since xml-models are comprehensive descriptions of models,
  you also find copy of inherited attributes in entities.

    PyModels takes care of this when loaded, although they also allow
  you to override the definitions of inherited attributes, if needed.
  The best of the two worlds ;)

> >  - make the framework correctly handle those flattened properties. As
> >    far as I can see, this would only impact the low-level bricks of the
> >    framework (esp. SQL generation for fetching and saving).
>=20
> I agree, this should be pretty straightforward, and could be implemented
> without breaking anything... people who don't use it wouldn't even
> notice it's there.=20

Sure.

> > Could you possibly elaborate on that? I never played with postgresql's
> > inheritance support, and it's probably something that could be added in
> > the User's Guide until vertical mapping is supported. If you find some
> > time to illustrate the mechanisms, I'll be interested in learning how
> > they behave wrt. the framework.
>=20
> Well, I haven't done much work with it personally either, but one of my
> pals here has. The story is that you can specify inheritance in a
> PostgreSQL database scheme. When you tell PostgreSQL that table Mammal
> inherits from Vertebrate, a "SELECT * FROM Mammal" will include all
> fields defined in Vertebrate as well. The interesting part is that the
> Vertebrate fields are actually stored in their own table...=20

  You really mean "*non-inherited* fields in Vertebrate are stored in
  their own table", don't you? (my turn to ask to make sure that we're
  talking about the same thing ;)

> think of it
> as vertical mapping implemented in the DBMS. So unique indentifiers are
> unique across all Vertebrates, regardless of whether they are Mammals or
> not.
> I have not tried this yet, but it looks to me that this could be used to
> put our application (which uses vertical mapping) in such a state that
> it can be used with the current framework.

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.

After having quickly looked at the postgresql doc. for inheritance, I
can see the following immediate pb. with such an approach: you won't be
able to fetch data from a specific entity alone, because the framework
will not issue the necessary 'select ... from only...'  statement, nor
it will fetch the 'tableoid' system field --so the 'isDeep' flag of
fetch() will have no effect. This could be a problem... or not! Be also
aware that, while pg accepts multiple inheritance, the framework does
not support more than one parent for a given entity.

  I'm not aware of the issues that Ernesto has raised in his recent
  post, but for sure this needs to be checked as well. Maybe related, at
  http://www.postgresql.org/docs/7.3/interactive/ we read:

    << A limitation of the inheritance feature is that indexes
       (including unique constraints) and foreign key constraints only
       apply to single tables, not to their inheritance children. Thus,
       in the above example, specifying that another table's column
       REFERENCES cities(name) would allow the other table to contain
       city names but not capital names. This deficiency will probably
       be fixed in some future release. >>

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

        Regards,

-- S=E9bastien.