Re: Generic UMO

[Anatoly Volynets <av@total-knowledge.com>]

It is never too late for an extra blessing, which you're getting from me
right now :)

Alexey Parshin wrote:
> Heh, it's better later than never. Especially that now I'm more convinced
> that it's possible to do the right way.. :)
>
> 2007/7/8, 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
>>
>>
>
>

-- 

Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org