Dave,
we just looked into the problem on our learn server. Although the original query (https://openacs.org/forums/message-view?message_id=1172094) returns a few thousand entries, we seem to have a different situation, since we have there a value for tag of 0 and not 1 as in your case. For us, all these entries have party_id = member_id and tag == 0. These entries come most probably from parties_in_tr(), which adds identity rows when parties are created. These parties are not users in our case. Since we delete only seldomly parties, these entries are there, they would be removed trough parties_del_tr(). So, I tend to believe that for our site, everything seems fine (but we have many differences from dotlrn, even in the data model).
Tom said
Offhand I would say that there is some confusion with tag.
.... the basic problem is that the field does not have a reference constraint ..... data model problem which was somehow abused by certain applications ...
In principle agreed. The name "tag" is bad, it is as well bad, that there is no fk. Others might know better than me (i am not a veteran from the ad days), but from looking at the code, i got the impression, the basic idea might have been, that "tag" is some arbitrary "client_data" (for maybe multiple purposes). In todays version it is used only for "0" or a rel_id.
Since the key of party_approved_member_map consists of (party_id, member_id, tag), tag can't be a NULL value, therefore a rel_id for the identity rows should be created (an identity rel) and added instead of the 0 when parties are added. Renaming tag to rel_id would help to avoid confusions. These are just my 2 cents.
This does most probably not help Dave with his original problem. Dave, do you have any idea, where the entries with tag=1 are added? Is there anything special about the party_ids and member_ids (are they equal, ancient, etc.)?
-gustaf
