[Nitro] Abstract classes in Og
richard at protea-systems.com
Tue Aug 1 20:17:31 EDT 2006
I've got a few comments/thoughts regarding abstract classes in Og.
I'd like to present some some ideas taken from Oryx, if I may (as I'm
seriously falling in love with Ruby, and you've got a really cooking ORM
going with Og). I think the most natural would be to define these simply
as Og derivatives which define no persistent attributes. That is, they
have identity, but no concrete state (they do hold meta-data, but more
on that later).
This would be modeled simply as a table with an oid column, and a column
holding the class name of the subclass, the instance of which a given
row in this table represents. To understand how this is useful, assume
that we have an association type called "has_many_ordered" which behaves
exactly like an Array where the link table as a third column of integers
which holds the array indicies (which you can order the collection by
during retrieval). Consider the following diagram for a simple CMS:
+------+ <Array> +----------+
| Page |----------| Fragment |
+------+ frags +----------+
| Paragraph | | Image |
Having an "has_many_ordered" (Array) association from one Og class
(Page) to an abstract class (Fragment) would allow you to fill the Array
association with a mixture of subclasses of Fragment (Paragraph and
Image instances). This is not normally possible using standard
relational concepts such as link tables. But we've got an OO data model,
so the way this works is that the primary key is generated from the oid
of the abstract super class (Fragment) only, and then supplied to the
subclasses as their primary keys when rows are inserted. This means that
in either the Paragraph or Image tables, the primary keys would be
sparse, meaning they won't be sequential and there would be gaps, such
that the sum of the set keys in both tables would be equal to the set of
the keys in the Fragments table.
However, the has_many_ordered link table only holds foreign keys to the
abstract Fragment class table, so when you try to retrieve an instance,
you need to know whether it's an Image instance or a Paragraph. To do
this, all you would need is to add a `realised_by' column to the
abstract class and a `super_id' column to the subclass tables which
would identify the derived class and super class instance, respectively.
Essentially, the abstract class table acts as a sort of link table
coupled with a sequence generator, and which stores the implementing
subclass name along with the oid, so that you can look up the subclass
and fetch the correct instance by it's oid directly. Am I making sense?
Anyway, I hope to do some cool stuff with Nitro/Og - I need to get into
the guts of Og though, got some additional features which I need:
extended_attributes (a sort of meta-model, with attributes saved as rows
in another table, instead of adding columns to existing tables),
has_many_ordered and has_many_keyed, but I've just been doing Ruby for
about a week, so initially the going will be slow-ish.
George Moschovitis wrote:
> have a look at this nice post:
> as always, your comments are welcome!
More information about the Nitro-general