[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Generic UMO
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
--
Alexey Parshin,
http://www.sptk.net