Forum OpenACS Development: Re: Bug in .LRN/openacs group memberships

This query shows that pretty much every rel type can develop this problem.

select distinct object_type from acs_objects o, acs_rels r, party_approved_member_map m where m.tag = 1 and m.party_id=r.object_id_one
and m.member_id = r.object_id_two
and o.object_id = r.rel_id;

         object_type
------------------------------
 dotlrn_admin_profile_rel
 dotlrn_admin_rel
 dotlrn_ca_rel
 dotlrn_cadmin_rel
 dotlrn_external_profile_rel
 dotlrn_guest_rel
 dotlrn_instructor_rel
 dotlrn_member_rel
 dotlrn_non_guest_rel
 dotlrn_professor_profile_rel
 dotlrn_student_profile_rel
 dotlrn_student_rel
 dotlrn_ta_rel
 membership_rel
(14 rows)

Offhand I would say that there is some confusion with tag. Why would a pl function take in something called a rel_id (p_rel_id), and equate that with a tag. In my mind, a tag is a string, but it must refer to something else, and the basic problem is that the field does not have a reference constraint. If it did, then only valid tags could be used, and then you could guarantee that the tag was unique. The pl function takes in a compound primary key, but the tag values are not enforced correctly to allow it to be part of a compound primary key.

So partly this looks like a data model problem which was somehow abused by certain applications. If the data model problem was removed, developers would have discovered that things didn't work very quickly, and would have fixed their code. But the API that was listed above is not necessarily in error. It might be the one correct piece in this, hard to say just yet.

I ran these queries with an old 5.0... version of OpenACS and didn't find any tags = 1, no object_id = 1. So I can't add anything to the meaning of the 1.