Re: Generic UMO

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

You fully convinced me. Not to mention the fact I wanted to do "generic
UMO" thing
from the very beginning :)

Anyways, you get my full approval - go for it.

Alexey Parshin wrote:
> In addition, a quote from latest PostgreSQL documentation:
>
> A serious 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. This is true on
> both the referencing and referenced sides of a foreign key constraint.
>
> In plain English, this means that any foreign keys or indexes put on
> the basic table are ignored.. This kinda defeats the purpose of having
> the generic UMO as a base for a particular UMO.
>
> 2007/7/8, Alexey Parshin <alexeyp@gmail.com <mailto:alexeyp@gmail.com>>:
>
>     After our discussion, I've reviewed the existing UMOs structure,
>     and came to the following conclusions:
>
>     1) Implementing UMOs using generic UMO as a base class doesn't
>     make much sense. Most of our UMOs use the same exact set of
>     fields, same set of methods, and same connections to other tables.
>     The only difference it would make is we may restrict the possible
>     foreign keys. The main disadvantage, however, would be the missing
>     support of such things from Umbrello. Currently, Umbrello simply
>     ignores derived classes while exporting to SQL.
>
>     2) The generic UMO has everything we currently need, besides
>     object type. With object type in place, we may have a single set
>     of { umo_base, umo_version, umo_content, umo_to_keywords,
>     umo_to_parent, umo_to_editor } tables, same goes for stored
>     procedures. That may significantly simplify the schema. We may
>     also have UMO-specific views, just to simplify SELECTs in the
>     interface and make 'em more readable. Another advantage is - we
>     can easily add new UMO type(s) by just adding a new record in an
>     existing table object_type.
>
>     3) If the need arises for an extra properties for a particular UMO
>     type, we can add a table to store such properties. Every property
>     may have a type (UMO-dependent integer) and a value.
>
>     I'm ready to change the schema to the generic UMO, but this is
>     pretty serious schema change - I need a confirmation that we are
>     on the same page.
>
>     -- 
>     Alexey Parshin,
>     http://www.sptk.net 
>
>
>
>
> -- 
> Alexey Parshin,
> http://www.sptk.net