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

[Federico H. <fh...@vi...>]

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.

Right. What I meant is that the XML constructs a flat view of the tables
making up the object.

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

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

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

Ermmm... in my example, Vertebrate is the superclass, so all of its
fields are non-inherited.

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.

>   About unique IDs: the framework takes care of assigning a unique ID (pe=
r
>   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.

So we don't use the automatic unique id generator in the DBMS... Doesn't
this break horribly in a multiple-address-space scenario?

> 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!

Indeed, this is something we'll have to look into.

> Be also
> aware that, while pg accepts multiple inheritance, the framework does
> not support more than one parent for a given entity.

Multiple inheritance is an abomination :-)

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

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

	Fede