On 11/12/05 3:03 PM, Mark D. Anderson wrote:
>>> 2. "Table per instantiable class" (aka "horizontal mapping")
>>> a table for each instantiable subclass. each table has all columns,
>>> including pkey and all inherited columns. There may not be anything
>>> to ensure pkey uniqueness across these multiple tables.
>>> pro: query by class is easy
>>> con: following a foreign key to a base class (can go to any subclass) is
>>> awkward
>>
>> RDBO supports this, since it's just a simple one-table-per class
>> relationship.
>
> Except for the "con" above. Consider the case where at a modeling level, some
> class member has a reference (foreign key) to an abstract class (e.g.
> "Contact") which could refer to any of the leaf instances. This gets awkward,
> to say the least -- either the foreign key value has to be structured
> ("vendor:17" or "customer:19"), or there has to be a discriminant column on
> the referring side.
Well, something like that is pretty much unavoidable. After all, in the
"horizontal mapping" case, there's always going to have to be some similar
way to handle a reference to an abstract "Contact" type because there is no
corresponding "contact" table.
> So it seems we are back to none of them being supported out of the box. That
> is not a dig at Rose; it is the embarrassing condition of all CPAN perl OR
> solutions, so far as I can see. Embarrassing, because even statically typed
> languages like C++ had solutions dealing with this stuff over a decade ago.
The trouble is that there's no single way to support even a single one of
these techniques, let alone all of them. What most Perl ORMs do is provide
the tools to support one or more of the inheritance systems you described.
Were someone to choose a specific way to support a specific approach, a
higher-level CPAN module could be produced by building on one of the
existing, lower-level Perl ORMs.
As for RDBO specifically, I'm still sorting out which are a best fit and how
best to support them. But even as things exist in RDBO right now, it's
possible to support the "one big table with lots of 'n/a' fields" approach
(I forget the name) using the magic re-blessing technique I described
earlier, and the "horizontal mapping" approach using a custom base-class
accessor (e.g., contact()) that calls the appropriate derived class accessor
(vendor(), customer(), etc.) based on which foreign key column is non-null
Also, having no experience with C++ ORMs, I'd be interested to hear how they
solved this in the past.
> Oh, and while I'm being grumpy, I don't see anything in the
> docs about the interaction between transactions and caching --
> another basic challenge in any OR architecture.
Rose::DB::Object does no caching at all. Rose::DB::Object::Cached in an
experimental subclass that does a primitive form of in-memory caching that
probably does not behave well when a transaction fails.
In my work, I tend to cache at a might higher level than database objects
(usually portions of or entire web pages) so I'm not sure how to design such
a system.
>> But even that is hard to "DWIM." It'd have to be explicit:
>>
>> package Book;
>> use base 'Product';
>> Book->meta(Product->meta->clone);
>> Book->add_columns(...);
>> Book->initialize;
>
> I guess I'm missing why those last 3 lines have to be explicit.
> Given all the other mysto-spooko stuff going on, surely DWIM
> is achievable?
The problem is, how do I know to clone the base class metadata? In nearly
all cases, this is not done. As far as I can see, there's no way for RDBO
to know when it should be done without being told in some way by the
developer. It could be more succinct than the example above. Say...
package Book;
Book->inherit_from('Product');
Book->add_columns(...);
Book->initialize;
and then with auto init, reduced further:
package Book;
Book->inherit_from('Product');
Book->auto_initialize;
but it basically boils down to the same thing: the choice to clone the base
class metadata object or not has to be explicit.
-John
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
