Thanks Don,
If my 'rephrased' summary comes close to what you were trying to say (and inheritance of 'core-attributes', like context-id, are ensured), I would be pleased.
Your words rephrased?........
" There are reasons from the past why attributes are used. However, in the future, I would like to see acs_attributes table being used more consistently for metadata (only); not as an intermediate to store values. (It would be nice to be able to describe attributes at a higher level, than at the PL/(pg)SQL level.) ".
If this could be a guideline, I suspect I should ignore 'table_name' of the acs_attributes table (it isn't used in the standard tarball anyway). Subsequently, I would stick to 'table_name' of the asc_object_types table for all common values and to 'type_extension_table', as an intermediate, to store all subtype specific values.
1. What would be a classic example for storage of data?
This brings me to another observation. 'Table_name' and 'type_extension_table' seem to exist for the purpose of metadata too. I queried the 'user' object in the acs_object_types table and I noticed that the user_preferences, user_profiles and user_portraits tables are not mentioned. Finally, acs_user was mentioned as package_name in that query, but this package is not defined in my package directory.
2. It think I can use any random-named table that references the object_id to store object values. Right?
3.(By the way, would it even be possible to enter more then one table name in the 'table_name' column of acs_object_types?)
Of course these are newbie-questions, but I cannot find an answer elsewhere and these uncertainties don't make life easier. So if you would be so kind to answer again, or someone else, then please.
