Interesting challenge: When a conflict occurs, my client does not want to bother the operator with the conflict resolution. So in most cases my client wants the conflicts to be solved automatically (which in the simpler cases is not that difficult - somebody changed an attribute on a record that does not affect your work, but does create a conflict when merging your workspace), unless the conflict is too difficult: then a message should simply say: impossible at this time.
So here is the workflow I have in mind:
User A creates a workspace wA
User B creates a workspace wB
User B edits attribute C of record 1234 in wB
User B Commits
User A edits attribute D of record 1234 in wA
User A Commits, gets a conflict
Software checks changes
sees that this change will not conflict
"reloads" original record 1234
makes the change on attribute D
Is this doable? I'd like to think so, but have no time for a real test in code.
Yes, this would be doable for any columns that can be compared for equality. Being able to compare for equality would be necessary to know which columns have been modified since conflicts are being flagged at the row level. Then it would be straightforward to make the necessary updates on the merged row(s).
OWM does not do this as there are cases when using both changes would not be correct due to business logic,etc. So, we leave it up to the application to decide whether or not to implement this type of functionality.
Thanks for the confirmation. Some preliminary tests that I have had the time for indicated this would be possible, but I really appreciate the opinion of an expert :-)
Some of the columns will be SDO_GEOMETRY, and they will provide the biggest challenge, but luckily in that case I can make use of the GIS-software my company sells, so while it will be a (Huge!) challenge to get all the Business Rules right technically I don't see any obstacles anymore.
we're not exactly having the same requirements as your customer does, but some quite similar ones.
that's a quite interesting scenario you have, so here's a question.
how do you do the "reload original record" thing? is it something like this?:
- user A begins merge session (whereas "session" means in our case the user opens the merge/refresh tooling of our application)
- detect conflict on record 1234
- load record 1234 (with the change C already applied) from wB
- add change D to the record
- store record 1234 with now changes C and D into workspace wA
- run merge and commit the change on record 1234 with conflict resolution set to KEEP_CHILD
- end merge session
we also thought about such kind of operations, though we never really got warm with it as we don't like the idea of applying automatic
background patches to data, but probably there is no real choice :)