Forum OpenACS Development: Re: Bug in .LRN/openacs group memberships
But the fact that it is a primary key should be a big flag that this needs to be an fk from (I guess) acs_relsNeither 0 or 1 are rel_ids (in acs_rels). So, if there would be a FK for tag, then there should be a different value chosen for the tag in case of the identity (the hypthical "identity-rel" mentioned above, which might be another magic negative value).
The purpose of the trigger is to establish the identity relation (party is approved member of party), which is there for achieving transitive closure (my interpretation, only interesting for transitve memberships).
However, this just source for confusion, not the solution for dave's problem, since we still don't know where the "1"s are from. Are there other dotlrn sites, with
select count(*) from party_approved_member_map where tag = 1;or is dave's site the only one?
Okay, here is an idea. Given the imaginary identity relationship which causes the row to be inserted into party_approved_member_map, I don't think that the original statement of the problem matches up this. The party_in_tr is inserting the identity, who knows why it is there, since it could be assumed that every party is that party. But the only way to remove it is to delete the party. The party_del_tr deletes all rows in party_approved_member_map regardless of tag. But the relational segment triggers only delete the rows which have a actual acs_rels.rel_id. So the imaginary tag prevents the removal of this identity row. Obviously this should be necessary. This is the trigger statement that leads me to this idea:
delete from party_approved_member_map where party_id = old.segment_id and member_id in (select element_id from group_element_index where group_id = old.group_id and rel_type = old.rel_type);
Anyway, in this case, the row is added by a trigger on parties, but 'not removed' by a trigger on rel_segments. This seems correct. But if someone uses a tag which corresponds to a real acs_rel, the identity row may be removed (maybe, not sure, maybe the tag should be changed to the party_id, since we know that id will never be an acs_rels.rel_id, or is there a guarantee that 0 will never be an object_id?)
So my question is: the data exists, but what problem is being caused by it? We never got any actual data rows, so I'm still not sure what would need to be fixed.
On a side note, Dave...the hardest bug to find is one which doesn't exist. But these types of bugs are easier to fix if you consider the possibility! Let's reconsider the actual issue.