Currently, PeopleMath assumes there is only one person heavily editing any given period at any time. This assumption causes problems for some users.
Each period is a single database object, protected by a single optimistic lock. Such mechanisms only work effectively under very low contention; heavy concurrent edits to a single period will result in lots of conflict messages telling you to reload and reapply your edits.
Saving is very frequent, so it's rare that a large amount of work is lost in such cases, but it's still irritating if you want multiple concurrent editors, rather than the single-concurrent-editor model which the current design assumes.
Finer grained locking would require non-trivial design work.
One idea would be to promote some part of the period data structure - perhaps buckets or even objectives - to first-class database objects with their own IDs, have REST endpoints for manipulating them, and then have a separate lock for each of the smaller objects, to allow concurrent edits to take place conflict-free as long as they are touching different objects.
Another idea would be to have functionality to do an automatic merge of two period edits, in cases where this was straightforwardly possible without conflicts (e.g. different objectives were edited without any reordering within the bucket). This could be done in the server side (pushing the new merged version of the period back to the client on save to pick up the external edits) or on the client side (the client subscribes for external changes to the period via websockets or equivalent, and constantly merges the changes locally, so that saves don't result in conflicts).
The most extreme approach would be to turn the whole period into some kind of CRDT but this would probably be rather tricky.
Currently, PeopleMath assumes there is only one person heavily editing any given period at any time. This assumption causes problems for some users.
Each period is a single database object, protected by a single optimistic lock. Such mechanisms only work effectively under very low contention; heavy concurrent edits to a single period will result in lots of conflict messages telling you to reload and reapply your edits.
Saving is very frequent, so it's rare that a large amount of work is lost in such cases, but it's still irritating if you want multiple concurrent editors, rather than the single-concurrent-editor model which the current design assumes.
Finer grained locking would require non-trivial design work.
One idea would be to promote some part of the period data structure - perhaps buckets or even objectives - to first-class database objects with their own IDs, have REST endpoints for manipulating them, and then have a separate lock for each of the smaller objects, to allow concurrent edits to take place conflict-free as long as they are touching different objects.
Another idea would be to have functionality to do an automatic merge of two period edits, in cases where this was straightforwardly possible without conflicts (e.g. different objectives were edited without any reordering within the bucket). This could be done in the server side (pushing the new merged version of the period back to the client on save to pick up the external edits) or on the client side (the client subscribes for external changes to the period via websockets or equivalent, and constantly merges the changes locally, so that saves don't result in conflicts).
The most extreme approach would be to turn the whole period into some kind of CRDT but this would probably be rather tricky.