This content has been marked as final. Show 3 replies
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 :)