Forum OpenACS Development: should the supertype of 'acs_object' be 'acs_object' ?

I'm playing with some dynamic-metadata stuff at the moment, and just noticed that the supertype of acs_object is 'acs_object'.

When the supertype argument to acs_object_type__create_type is either null or the empty string it is forced to 'acs_object', which sort of defeats the purpose of allowing null supertypes and means that the object type hierarchy doesn't make sense. It also means I need to special-case updates when I reach the acs_object behind any other object.

I'm assuming that acs_object_type__create_type behaves the way it does so that lazy package authors can pass a null supertype when creating their own types and still have something correct-ish happen. Personally I'd suggest removing the default supertype from acs_object_type__create_type, but if the current behaviour is seen to be desirable how about special-casing the creation of acs_object to allow it to have a null supertype?

We should not break things for existing packages, but adding a flag / special reserved word for a "null" supertype would be okay I think.

What I wonder is this: Which types of objects should *not* have acs_object as a supertype. And why does the object type hierarchy not sense (acs_object is the root type) ?

Collapse
Posted by russ m on
Which types of objects should *not* have acs_object as a supertype
*acs_object* itself should not have acs_object as it's supertype. acs_object should have a null supertype.
And why does the object type hierarchy not sense
Because it doesn't currently have a well-defined root. Do a
select object_type, supertype from acs_object_types;
and then try manually climbing the object hierarchy. How do you know that you've reached the root?
I would do a "select object_type, supertype from acs_object_types where object_type != supertype" and then start climbing :). Okay, it is not semantically correct but should achieve the goal.

Either way, I'm fine with the proposal to change acs_object into having a "null" supertype, not sure though if the upgrade is as trivial as I'd hope. Let's wait and hear what the others say. This needs to be Tiped anyway in the end.

Collapse
Posted by Jeff Davis on
I think the reason the root supertype was not NULL was because oracle does not index nulls. The acs_object_types table is so small that it does not matter one way or the other though.

Russell, is there any reason you can't just use the code as is using supertype = type where you want to create a new object type root?

Collapse
Posted by russ m on
Jeff - I'm not wanting to create a new root to the object hierarchy, I'm just climbing from a specified object_type to the root to see what attributes the type and it's parents have. I can easily enough special-case 'acs_object' and stop climbing then (that is in fact what I'm doing now), but it seemed to me that the current situation was not semantically correct and was probably just an unforseen side-effect of making acs_object_type__create_type more "friendly".
Collapse
Posted by Jeff Davis on
Oh, I see.

Actually I was talking out my ass anyway, the reason it's not null is the pg port is borken with respect to the oracle version. On oracle the supertype param is defaulted to 'acs_object' but when acs_object is added as an object type the param is set explicitly to null.

On pg, you don't have parameter defaulting so it can't distinguish a supertype you want to have be null from one where you just want the default.

I think we should special case the acs_object object_type create to leave it null in pg as well.

Collapse
Posted by Dave Bauer on
Russell

There is already a procedure to tell you all the attributes for a type.

package_object_attribute_list is a private procedure of acs-subsite in package-procs.tcl. No this does not make any sense, but it does come in handy.

You will probably find some other procedures that are useful for what you are doing in there as well.