Forum OpenACS Development: Attribute "tag" in party_approved_member_map

Collapse
1: Attribute "tag" in party_approved_member_map
Posted by Gustaf Neumann on 06/01/16 11:08 PM
Has anyone interest on keeping the attribute "tag" in "party_approved_member_map"? The tag attribute does not exist in Oracle (portable applications cannot depend on it). Nobody seens to use it (checked all packages in CVS and from PO), it is not mentioned in the design documents, and it causes sometimes harm (see [1]).

It seems to me as we should drop this attribute, since party_approved_member_map reaches on some of our installations several mio entries, and the "tag" field contains sometimes garbage (deleted membership rels, since it has no fk).

[1] https://openacs.org/forums/message-view?message_id=1172094

Collapse
2: Re: Attribute "tag" in party_approved_member_map (response to 1)
Posted by Gustaf Neumann on 06/02/16 08:21 PM
Actually, Guenter Ernst figured out, why the "tag" attribute is needed. The reasons are composite rels in openacs. It is possible, that there are redundant reasons for being an (approved) member, and when only one of these redundant entries is deleted, the other one has to stay (the "tag" disambiguates the entries). The Oracle variant does this via refcounting, i have no idea, why postgres does it differently.

However, the following should be done to reduce the guesswork:
a) rename "tag" into "originating_rel_id"
b) replace the "0" of the sellf-membership by a NULL
c) define a fk for "originating_rel_id" to acs_rels.

Collapse
3: Re: Attribute "tag" in party_approved_member_map (response to 2)
Posted by Gustaf Neumann on 06/24/16 06:58 PM
The details of the change were a little more involved: A NULL value was not possible, since the field is part of the primary key (which is always not NULL). Therefore, it was necessary to introduce an "identity_rel" (magic value -10) which serves as a special value, and it allows to use a fk to acs_rels.

These changes are now committed to the oacs-5-9 branch.

The Oracle version us quite different, it uses a ref-count instead of the "originating_rel_id", where the latter makes it easier to understand the whereabouts of the values and eases deletions, etc.