UniverseUniversity
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Generic UMO
Right :)
2007/7/20, 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
--
Alexey Parshin,
http://www.sptk.net
Authoright © Total Knowledge: 2001-2008