[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Generic UMO
- To: uu@total-knowledge.com
- Subject: Generic UMO
- From: "Alexey Parshin" <alexeyp@gmail.com>
- Date: Sun, 8 Jul 2007 09:24:49 +1000
- Delivered-to: mailing list uu@total-knowledge.com
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=JDxBum6vXTWGQifGeYYK6FFy1kPMPt7j+m04K/RcJM4F0u5L0DmRf3PL9KFifhQTtdEX1wTBaqQWSUNO4xKHSV+u7AQtjMgxRl4looK+pW0XhO+JV9Y85hXf4mUo1xZxNe/AZn93B/g6iLbeT/rbAb90vXbO3xBwHePvdLeZ0k4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=X1pdhlTSmlszmSH4t8cNHsi4iQLFlrlS9M0dmdbw4OJPyhSzDaHFegc0WHPwenFFTkjjGaMiLD5YcW1olZi9WUlmCBsJFQEEFG9ccaZilweQZ8bBME7oIx5PVipRkWkYC9BgpdwRVNWU1kI19KnCKBM01yAT4yCY14UmZ0F5b+k=
- Mailing-list: contact uu-help@total-knowledge.com; run by ezmlm
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