Forum OpenACS Development: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields

Let me bring up a couple of reminders ...

Adding extra columns is not zero-cost in PG when the values are NULL.  Every row has a descripter which includes column metadata - adding new columns increases the size of that descripter regardless of the value stored in the column.

I had though we'd talked about deriving a "named_object" type from acs-objects and to carry denormalized data like name and URL there?  Rather than extend acs-object itself?  I thought we'd had consensus (more or less) that package_id was the one candidate that belongs in every object?

While I understand Tom's objection to having package_id in each object this particular problem has cropped up so often and has resulted in so many packages having a package_id field in its private object type that I think it is worth doing.  If all packages do it the same way maybe all of them will do it right :)

I've been thinking actually in terms of reworking the relationsip between objects and cr_items in a way that would more or less give "named_objects" as well as remove one object  in the case where one wants to define content types that aren't revisionable.  I don't have any details beyond that but I'd really like have us spend some time thinking about improving the datamodel holistically rather than just kludge it up to solve a couple of performance issues.

Anyway I've been thinking about this quite a bit and want to do some experimentation after 5.0 is released ...

What is the penalty of a NULLed column in PG? In Oracle it's one byte per field unless it is the last field in a table, then it is zero bytes.

My goal - the TIP's goal - is to have crucial data easily and cheaply available. The packages I (and Tilmann) have mentioned are not available or in a really rugged state. It is so not only because nobody has yet volunteered to take care of them, it is also that OpenACS' data model is not finished.

Quoting myself from this very thread:

Name - exactly as in cr_items. Does it make sense to duplicate this? Probably not, especially as cr_items already has locale, content_type, publish_status etc.

I haven't talked about performance here btw. This is about functionality, that is imho currently direly missing from OpenACS. (I only ruled out PL/SQL as a means of achieving my goals)

Maybe we can move forward because I think there generally is a consensus. We have a few options on how to implement this:

* add a whole slew to acs_objects

* create a table acs_objects_description (sic! that is how I named this table in the Sharenet project :)) that holds name, locale, verbose description and what not. (Package_id still goes into acs_objects)

* Use cr_items instead of acs_objects_description. Advantages here: reasonably well-understood TCL api already exists, the table already exists and is quite fat anyway.

Did I forget something?

Oh yes, what about doing this in a different thread?

My thoughts on the package_id was that first it only makes sense with some object types. In the cases where it makes sense, it could just as well be that an object needs to be related to more than one package. However, I only use a tiny subset of OpenACS. If it greatly simplifies things maybe it is the easiest solution.