acs_attributes are not just for multivalued attributes, they support
recording attributes of objects which are unknown at design time.
The choice comes down to: 1. alter tables at runtime to add extra
columns, or 2. model the RDBMS in the RDBMS. There are
advantages and disadvantages to both approaches. (The old aD
KM bboard has some interesting perspective on this, as they
switched between the two methods).
The simple-survey package re-implements such an attribute system
for it's questions and answers. ACS3 has a simillar system for
custom information to be gathered for groups and groups types.
The old event module allows administrators to define custom
attributes for activities and events. Each of these packages
re-implements the same set of features (with a new set of bugs).
Problems with the current acs_attributes system include:
Everything has to be coerced into a clob. I think there's a comment
in the code about this, it shouldn't be too difficult to switch to a
simple-survey-like integer_answer, date_answer etc. set of
columns. Only objects can have attributes, not object types. I
would really like to see
acs_object_types become acs_objects themselves. (Add more
gripes here...)
So, I'd rather not see the acs_attributes system dissapear. It needs
to be fixed, enhanced, and used extensively.
