Forum OpenACS Improvement Proposals (TIPs): Re: TIP: Composable rel types
Regarding the first of your two points re: the patch, the composable flag isn't ignored when membership relations are added; if a membership relation (or subtype) is added to a *component* group, the flag is checked to determine whether or not that relationship should be added to container groups. In practice, however the flag will have no effect on most installations because most installations will have no component groups. The second point is correct.
Your question re: semantics when a given type is composable and an ancestor is not is a good one. I think it's unclear because such an organization of subtypes doesn't make much sense. The approach I think I would favor would be to enforce false on all further subtypes of once composable is set to false (via trigger on acs_rel_types). Would that clarify things in your view?
I'm not sure I understand your comment about membership relationships being at the top of the hierarchy thus never being used. Can you explain?
I think it's true generally that membership is what most developers and users will be interested in seeing propagated from component to container and that is usually implicit when you are creating components as subgroups (there are probably some cases where subgroups shouldn't be components but that is another subject). I can think of some benefits of composition in other types, however. For example, part of our type hierarchy looks like:
member
physician
first_year_resident
...
and an example group hierarchy might look like:
Some Healthcare Organization
Hospital X
Department Y
Consider the case where you have have "First Year Residents" in Department Y. When you have an organization with multiple teaching hospitals, it might be useful to see "who are all the first year residents at Hospital X" or even "in the entire organization" or to assign this grouping some privileges at the hospital or organizational level. If the first_year_resident role propagated, this would be easy. I think it's worthwhile to afford (or rather, to not rescind) this flexibility.
I like the idea of automatically adding implied rel types. I think that is what most developers and users would expect when adding a role from a hierarchy. If you look at how the existing code functions however, an admin_rel added using the pgsql functions (or relation_add) results in a new row in both membership_rels and admin_rels but only an admin_rel in group_member_map. This could/should be corrected but I think it is a separate issue and deserves its own discussion/TIP.
Regarding your latest post, I agree about the complexity and its funny you should mention recursive queries; I also wondered whether or not we could use those techniques to simplify the group membership tables/maps while working on the composition issue. That's also a separate issue too but it's related to the type hierarchy issue above.
If we could make a determination regarding the idea of composable relationship types here, we could investigate the other issues in another thread.
i think we have similar goals: to provide for large organization scalable, differentiated and somewhat decentralized membership- and rights management. It seems to me as if the existing code base of OpenACS was developed in various layers (the often deeply nested views), competing concepts (e.g. groups and memberships rels) and APIs (and existing APIs often not used, e.g. in www directories of the admin pages of subsite and friends). Dealing with these code layers is probably the bigger issue than the original problem.
We (mostly victor) have already done some work with membership management and recursive queries that could be used as a basis. Probably, the easiest path might be
- define intended semantics based on recursive queries
- define stored procedures and a new tcl-api
- mark existing infrastruture as deprecated and replace it stepwise
- for the existing sql-structures/queries/api, one has to maintain the materialized tables and triggers for a while (similar as for the recursive queries we did for permissions)
- we have to maintain the existing sql-structures/queries/api for Oracle as well, although i would expect that porting the recursive queries to Oracle is straightforward.
As for the TIP:
- as it is, it does not hurt
- we should make clear that it is not recommended to pursue this way in the future, but to see this tip as a transitory step
- i would recommend to set the flag to false for all reltypes
having this said, i approve if it helps you in a transitional phase...
