Forum OpenACS Development: cr_item_rels needs relaxation

Collapse
Posted by Timo Hentschel on
For assessment to work properly we need to relax the constraint in cr_item_rels binding the relationships only to cr_items. We need that to be totally open so that we can implement relationships between two cr_revisions. The only thing needed is to drop that db-constraint, create a new plsql  proc for cr_revisions and add that functionality in tcl to create relationships between cr_revisions.

To be exact, we need that functionality in the 5.1 branch. Is that ok or are there any major objections?

Collapse
Posted by Dave Bauer on
Please do not do this. This totally changes the way CR is used and I really don't see a need for it. If the assessment package has specific needs to relate different revisions please create an assessment specific table to handle it. This level of change must be handled as a TIP anyway, but I think there may be a misunderstanding in the assessment package use of the content repository if you think this is necessary.
Collapse
Posted by Don Baccus on
What Dave said - with emphasis.

What exactly are you trying to do, Timo?

Collapse
Posted by Timo Hentschel on
In the assessment package we have questions that have some general data. But then we need to attach some question-type specific data and some display-type specific data which we now do with cr_rels in the cr since every information in assessment goes to the cr anyway.

When some data of a question is edited, a new revision is generated, but old mappings to that old revision should not see any change! Since the data in the mapped type-specific items can change, too, we really need a mapping from revision to revision.

Quite frankly, I don't see a problem in relaxing this thing a little bit...

Collapse
Posted by Don Baccus on
Just build your own mapping table, among other things cr_rels is built on acs_rels (I believe?) which means each is an object which is horrible overkill for your use.
Collapse
Posted by Don Baccus on
Why not just add the revision foreign keys directly to your revision type rather than deal with a mapping table at all for this case?

It sounds like you're tying revisions tightly together, which, as Dave points out, is CR abuse, but if it's justified ... why not do it directly?  Or is this a many-to-one or many-to-many mapping (if true then a custom mapping table seems like the right thing to do).

Collapse
Posted by Malte Sussdorff on
We do indeed deal with many-to-many relationships and the assumption at the beginning was to deal with it through cr_rels. Well obviously I was wrong, so we will just use an assessment wide mapping table.