Re: Generic UMO

["Alexey Parshin" <alexeyp@gmail.com>]

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

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