Forum OpenACS Development: dumb acs object model questions

Posted by Barry Books on
There are a few things about the acs metadata model that have always bothered me.
  1. Why are acs_object_types, acs_attributes, acs_datatypes and enum_values not acs objects?
  2. What do min_n_values and max_n_values in the acs_attributes table do? Are they min and max values for the attribute or the min and max numbers of attributes?
  3. Why not a required_p in acs_attributes?
  4. What is max_n_values in the acs_datatypes for?
  5. What is the real purpose for enum_value and enum_prettyname. It seems to just cause grief if you store the enum_value in the database since you have to convert to display and search.
  6. Why can't you put anything in acs_attributes.table_name
  7. It would be nice if acs_object.set_attribute/get_attribute worked like so you could deal with problem data.
  8. Why are acs_object_types not acs_datatypes so objects can contain other objects?
This is not really a complaint. I'm working on yet another interface genertating package that lives on top of the metadata and it seems a few things are missing or not clear. I've implemented the first one and it seems very useful. Any comments?
Posted by Don Baccus on
Object types should be objects, or at least that's the conclusion some of us have reached in earlier discussions.  The main issue would be the writing of upgrade scripts that wouldn't break existing sites.  A couple of us have discussed implementing "object proxies" (our made-up term) for object types that would give us an object handle for an object type in a way that would make upgrading existing installs easy.

acs_attributes ... if they were objects one could use permissions to control who can read/modify object attributes on a per-type basis.  The expense involved here would be relatively low.  If each attribute value were an object (giving permissions control over attributes at the per-object level) the expense would be horrendous, so that won't happen.

min_n_values and max_n_values govern the min and max numbers of the attributes you can assign to an individual object.  Obviously this doesn't work with attributes stored directly as columns in the object type's table, only for those stored using the (slower) generalized attributes table.

enum_value and enum_prettyname ... software engineers seem to believe that identifiers can't include spaces even if they're surrounded by quotes for some reason. :)

your last question is related to the first question and that has been discussed, too.

In general, I think you'll find that many would like us to move to a more lightweight object model rather than a more heavyweight object model, and some of your ideas might be viewed as moving towards the heavy end of the scale.  In practice the more dynamic aspects of the object model are rarely used by package authors.

Posted by Barry Books on
Your view of max_n_value/min_n_value is the same as mine but I don't see how to implement them with the generic storage either. The table has a primary key of object_id/attribute_id which I think means 1 per object. Also the get/set_attribute interface only supports 1 per object.

It seems the most used part of the data model is permissions. The meta data is rarely used. I just wonder if there would be more interest if there were more support. To me hooking the meta data to the form templating could be very usefull. The problem is I think they are some of the least used and least understood pieces of the toolkit.

Posted by Don Baccus on
There are hooks to do as you suggest, but it's incomplete.  I know Jeff Davis is looking at some of the pieces.

There's a lot of duplicated functionality in the Content Repository (CMS/CR started as a standalone piece of software.) But the stuff there mostly/sorta works and is going to get better rapidly.

But, yes, using metadata to automagically generate forms and all that's has been/is being talked about and I think stuff will happen here in the next few months.

And, of course, if you're interested in helping out you are are more than welcome to do so.