Forum OpenACS Development: cr_revisions linking problems

Collapse
1: cr_revisions linking problems
Posted by Eduardo Pérez on 10/13/04 09:16 PM
We see problems using cr_revision as primary key when referencing other objects in the CR.
For example, right now we have in the table as_assessment_section_map a reference to the as_assessments (assessment_id) and as_sections (section_id) the two of them being a cr_revision, so if we change an assessment then it gets a new cr_revision and if we don't update all the tables that have a reference to that cr_revision the new assessment won't see the sessions linked.
jopez told us about these problems and we see that it's not a good idea to reference by cr_revision and better reference using the cr_item
Initially we were using this scheme of linking using the cr_revision to prevent someone modifying a choice, item, section or whatever to change an already working assessment that shouldn't change to prevent changes to assessments already answered that should be locked from modifications
So, with the new approach when an assessment enters in visible (or answer) mode, it should be locked and all the sections, items and everything else should also be locked from modification. Maybe we should add a column in every table (like "locked_p") and something in the editor telling that the entry is locked and should only be modified for typos as much.
If someone wants to start with an existing locked assessment he should copy everything that wants to change into a new different cr_item.
Shall we go on with this change in assessment package?
Comments? Suggestions?
Collapse
2: Re: cr_revisions linking problems (response to 1)
Posted by Malte Sussdorff on 10/14/04 09:06 AM
The CR has a published state (or live state) for one revision, noting that this is the live revision. You should be able to use this for your "locking" feature, meaning, if an assessment is enabled, do not update the live status of any change you make.

Furthermore, it is a *very bad* idea to not use cr_revisions for questions unless you make every change to a question a new cr_item (new question). Reason:

1) Professor A creates question Z.
2) Professor B uses question Z in his assessment.
3) Professor A changes question Z.
4) Professor B is notified of the change and can decide, if he wants to use the changed question in his assessment or not.

Now, if we use cr_revisions, the decision made in 4) only changes the revision. If we use as_items though, 3) triggers the creation of a new question and you have to make sure that B get's notified of that change and that all statistics across question Z take all derived cr_items into account as well (as the change might be just a typo, which would not nullify all results).

Continuing down that road, it is after all possible to reuse sections. So the same problem applies for sections as well. As for assessments, yes, if you change an assessment, you have to change the revision_id as well, unless you create a function that gives you the "live" revision based on any revision_id.

Last but not least, you have a pretty good idea, where the cr_revision is referenced, which is something you need to do anyway, because you can assume that if Prof. A changes question Z he wants to see that change in all his assessments. Well, actually I'm not so sure about this. So the UI would have to provide the professor some information about the implications of his change (e.g. show all of *his* sections where the question is used and ask for which sections the professor wants to change the question). Last but not least, every change in an assessment or a question may or may not trigger a recalculation of the final result.

To sum it up, in my opinion you have two options:

a) continue to use cr_revisions and propagate the changes.
b) use cr_items and link all cr_items that derive from each other together (which is the approach taken by the localization of content, if I'm not mistaken).

Either way is fine with me, but the implications should be made aware and taken into account when developing.