Forum OpenACS Development: Help on understanding acs-rels
In my OpenACS system, I have to create a relationship between users, organizations and dotlrn communities, assuming that all the organizations stuff is going to be in a subsite. I was creating my relationships with auxiliary tables, wich were going to create a relationship between the community_id and the organization_id and another between the user_id and the organization_id, when I found out about acs-rels.
I've read Rubick's doc about it (http://rubick.com:8002/openacs/acs_rels) and I've searched the forums about it too, but it still looks a little dark to me. Taking a look at the contacts package, I realized that it creates a relationship named organization_rel, supposed to be between a group and the organization. I've tried to do something similar using the rel_types::new API. I also understood that you have two objects, each one carrying a role, wich creates the relationships. What I don't understand is: how do I map these relationships?
My relationship creation example:
rel_types::new -table_name "organization_rel_training" -create_table_p "t" -supertype "organization_rel" -role_one "community" -role_two "training" "organization_rels_training" "MESSAGE KEY MISSING: 'organization.Training'" "MESSAGE KEY MISSING: 'organization.Rels_Training'" "dotlrn_community" "0" "" "organization" "0" ""
For example: what's the table that tells me the object_id for the related objects? How do I map that?
Another question: I've created one instance of organizations in my subsite. However, the organizations I create there can't be seen by the contacts package. Can somebody tell me why is this happening?
1 - When you create the coach_rel type, the reference table is the coaches_ext, in the column coach_id. Is this the table you crated? The UNICYCLIST_EXT when you create a subtype of user, did you create it too?
2 - When you reference an object, does it have to be a group?
I'm sorry for the questions, but it seems a little bit complex to me.
Also, the new groups which get created don't have any extension tables by default, but they can be added.
Focus on the use of acs_rels: this make it easy to do queries to find both sides of a relationship, then you have a reduced set to do permissions checking on, but driving very targeted queries is a big benefit of acs_rels.
I've been working on a generalized object relationship model, very similar to RDF which is easier to understand, but the acs_rels concept is general, integrated with OpenACS, but difficult to setup.
More specific to this example:
1. users and groups are created normally.
2. additional membership relationships are used to relate these users and groups
3. membership is granted to main site
4. admin permission is granted to new user over new group.
Note: the new group is to allow for a central point for relationships between users (cyclists, coaches, parents, clubs).
The example demonstrates that without the need to create any additional tables, you can model complex relationships and query them pretty easily. Of course the individual groups can then have unique extensions which don't affect the structural/permission relationships.