[Nitro] Abstract classes in Og

Richard Hundt richard at protea-systems.com
Tue Aug 1 20:17:31 EDT 2006


Hi again,

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:


                    <ABSTRACT>
 +------+  <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.

Cheers,
Richard




George Moschovitis wrote:
> have a look at this nice post:
>
> http://nitroproject.org/blog/articles/7
>
> as always, your comments are welcome!
>
> -g.
>
>   



More information about the Nitro-general mailing list