Forum OpenACS Improvement Proposals (TIPs): TIP #80 (Rejected): Add dynamic_p to acs-attributes

The reason for this TIP is to add a field "dynamic_p" to acs-attributes.

This field shall store the fact if the attribute was generated by a package (dynamic_p = 'f', which is the default) or generated by a dynamic attribute methodology as is provided by dynamic types.

This allows to differentiate between dynamic attributes that should be presented using the dynamic attribute generation methodology and other attributes.

Collapse
Posted by Malte Sussdorff on
This is going to be a prerequisit to a TIP which might follow at a later stage to merge dynamic types and AMS into core to support extensions of existing object-types with *additional* attributes.
Collapse
Posted by Jade Rubick on
For reference:
create table acs_attributes (
        attribute_id    integer not null
                        constraint acs_attributes_pk
                        primary key,
        object_type     varchar(100) not null
                        constraint acs_attributes_object_type_fk
                        references acs_object_types (object_type),
        table_name      varchar(30),
        constraint acs_attrs_obj_type_tbl_name_fk
        foreign key (object_type, table_name)
        references acs_object_type_tables,
        attribute_name  varchar(100) not null,
        pretty_name     varchar(100) not null,
        pretty_plural   varchar(100),
        sort_order      integer not null,
        datatype        varchar(50) not null
                        constraint acs_attributes_datatype_fk
                        references acs_datatypes (datatype),
        default_value   text,
        min_n_values    integer default 1 not null
                        constraint acs_attributes_min_n_ck
                        check (min_n_values >= 0),
        max_n_values    integer default 1 not null
                        constraint acs_attributes_max_n_ck
                        check (max_n_values >= 0),
        storage         varchar(13) default 'type_specific'
                        constraint acs_attributes_storage_ck
                        check (storage in ('type_specific',
                                           'generic')),
        static_p        boolean default 'f',
        column_name     varchar(30),
        constraint acs_attributes_attr_name_un
        unique (attribute_name, object_type),
        constraint acs_attributes_pretty_name_un
        unique (pretty_name, object_type),
        constraint acs_attributes_sort_order_un
        unique (attribute_id, sort_order),
        constraint acs_attributes_n_values_ck
        check (min_n_values <= max_n_values)
);


comment on table acs_attributes is '
 Each row in the acs_attributes table defines an
 attribute of the specified object type. Each object of this type
 must have a minimum of min_n_values values and a maximum of
 max_n_values for this attribute.
';
Collapse
Posted by Jade Rubick on
I'll approve, although I wouldn't mind a more clear name if we could come up with one. I would have very little idea what the column meant unless it's well commented.

I think core data model changes do require a TIP, unless they are obviously broken.

I would propose another name for that field, because there is another one called "static_p". I think it may provoke misunderstandings.

One of those other names could be, for instance, "created_by_user_p", maybe for short "user_p", or the opposite "package_p".

Collapse
Posted by Jeff Davis on
I think we might want something other than dynamic_p like a managing package or something, eg if we have more than one dynamic types package (which we do now right?) a simple boolean won't really do it, I would think we would want something like "managing_application" which could be system, ams, dynamic-types, etc.

In any case, I think it's late for 5.2.

Collapse
Posted by Malte Sussdorff on
I don't think we should add this into 5.2 either. I like Jeffs idea of a managing_application though the goal for 5.3 should be to at least merge AMS and dynamic types functionality into one. But this is a different discussion.
Collapse
Posted by Dave Bauer on
One thing to consider is that the original design on ACS 4 apparently intended the developer to subtype a particular object type, and store all the dynamic attributes there, rather than extending an existing type.

I think it is useful to store the extended data in the same table, but there needs to be some way for the managing package to cleanup after itself and remove the additional attributes, if the package is dropped.

So I think keeping track of where the dynamic attributes came from is definitely useful.

Collapse
Posted by Malte Sussdorff on
Is the term "managing_application" okay? If yes, we would commit this change to head in a couple of days (as there are no "No's")
Collapse
Posted by Jeff Davis on
Can we please specify what the obligations a "managing application" should meet - ie. should it provide a rendering callback, i18n names for the attr, etc. I don't want this to be the same as many other "features" that do not have well defined functionality just don't get used (eg properties for ad_page_contract).