"Relationships" are generic N x M mapping between OpenACS objects.
Relationships can have parameters associated, constraints on the object types of both sides of the relationship and being objects themselves, they can be subject to permissions themselves.
Table |
Cols |
Rows |
Description |
---|---|---|---|
[acs_rel_roles] |
3 |
10 |
List of relationship "roles". Example: A user may be related to a company in the role "Employee". |
[acs_rel_types] |
9 |
12 |
Each row in insert into acs_rel_types (rel_type, object_type_one, role_one, min_n_rels_one, max_n_rels_one, object_type_two, role_two, min_n_rels_two, max_n_rels_two) values ('employment', 'person', 'employee', 0, null, 'company', 'employer', 0, null) defines an "employment" relationship type that can be expressed in in natural language as: A person may be the employee of zero or more companies, and a company may be the employer of zero or more people. |
[acs_rels] |
4 |
1838 |
The acs_rels table is essentially a generic mapping table for acs_objects. Once we come up with a way to associate attributes with relationship types, we could replace many of the ACS 3.x mapping tables like user_content_map, user_group_map, and user_group_type_modules_map with this one table. Much application logic consists of asking questions like "Does object X have a relationship of type Y to object Z?" where all that differs is X, Y, and Z. Thus, the value of consolidating many mapping tables into one is that we can provide a generic API for defining and querying relationships. In addition, we may need to design a way to enable "type_specific" storage for relationships (i.e., foreign key columns for one-to-many relationships and custom mapping tables for many-to-many relationships), instead of only supporting "generic" storage in the acs_rels table. This would parallel what we do with acs_attributes.
|
[composition_rels] |
1 |
17 |
Relationships of type "composition rel". These are relationships between groups, indicating that one group is included in another group. |
[group_rels] |
3 |
9 |
Stores the relationship types available for use by each group. Only relationship types in this table are offered for adding relations. Note that there is no restriction that says groups can only have relationship types specified for their group type. The |
[group_type_rels] |
3 |
9 |
Stores the default relationship types available for use by groups of a given type. We May want to generalize this table to object_types and put it in the relationships sql file, though there is no need to do so right now.
|
[membership_rels] |
2 |
638 |
Sub-class of acs_rels, describing the relationship of users being member of a group. |
[rel_constraints] |
5 |
0 |
Defines relational constraints. The relational constraints system is intended to support applications in modelling and applying constraint rules on inter-party relatinships based on relational party segmentation.
|
[rel_segments] |
4 |
2 |
Defines relational segments. Each relational segment is a pair of |
Calle Aprestadora 19, 12o-2a
08902 Hospitalet de Llobregat (Barcelona)
Spain
Tel Europe: +34 609 953 751
Tel US: +1 415 200 2465
Mail: info@project-open.com