Forum OpenACS Improvement Proposals (TIPs): TIP #86 (Approved): Allow a null table name associated with an object type.

The purpose of this TIP is to allow subtypes with no type-specific table. This is useful particularly for the "template" object type, which needs no additional attributes not already described by cr_revisions, but needs to be differentiated from a garden-variety cr_revision.

The change would require:

1. Dropping the not null constraint on acs_object_types.table_name;

2. Fixing the view-generation SQL in content-type.sql and the few other queries in the CR that depend on that column having a value.

The change will not affect existing content types.

The change will not affect existing content types.
EXCEPT acs_message_revision, table_name='CR_REVISIONS' will be changed to NULL
EXCEPT file_storage_objects, table_name='fs_root_folders' will be changed to NULL

and anyplace else that abuses the system to work around the fact that acs_object_types required a type specific table even if the object type did not have any unique attributes.

Okay, I've reviewed this a bit.

I don't see any reason to force the creation of id-only extension tables on people who only want the other stuff that acs-objects provide (audit data, permissionability). We need to de-cruftify.

To repeat what's probably an assumption, as part of this TIP you'll have to grep through and fix any code that expects non null values here. I found the acs_object_types table popping up quite a bit in the acs-subsite/admin pages, something you didn't mention.

Also, while you're at it, you almost certainly want to drop the not null constraint on id_column, and probably on package_name as well.

Bottom line: APPROVE

approved ...

Not sure about dropping the not-null on the package name, though ... code like the object instantiation code depends on being able to find package_name.new() etc, and we're encouraging people to use these Tcl APIs rather than build objects by hand in order to simplify the writing of code supporting both RDBMSs.

Actually I think Andrew's right, we should fix the Tcl API code to work with null table, package, and id column name by running up the type derivation tree until we find one which has non-null values.
Actually I think we should leave package_name not null, and allow for table_name and id_column to both be null or both be not null.

acs_object_type.new() sets the package_name to the object type if "null" is passed in and I don't think we should touch the semantics here ... letting it be null wouldn't break code but would require work on package_instantiate_object and similiar API code and since it's already being forced to a package name ... let's keep that.

Just my thinking ...

A slight fly in the ointment ...

The CR views are created using the associated table name as the base, not the type name. The easiest thing to do is to not create the view when no table name is specified, but this will break code if later a table is added to the type ...

When we implement the equivalent to CR views for acs object types we should use the type name as the base rather than the table name ...

Surely I am wrong, but I do not understand why you need a "null " type. Would not it be better to have a "not-specified" type (of course, child of "object" type)?. In fact, it would not require any change on any part of the code.
The object type is not null, just the table_name column is acs_object_types, since the object_type itself is the only additional attribute of a subtype. Two places this comes up frequently are acs_rels, where you need to differentiate between rel types but don't need additional attributes, and content_revision subtypes where you need to know the content type, but don't need to add additional attributes.
Ooops!, I replied too quickly.
Don,

Can we just create a view using coalesce(table_name,object_type) or nvl(table_name,object_type) so that existing code behaves the same and tableless types still get a view? Otherwise the content::revision::new and any code relying on views will break.