3 Replies Latest reply: Oct 1, 2010 2:33 AM by aschilling RSS

    Building semi-automatic conflict resolution

    Stefan Jager
      Hi All,

      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
      Commits again

      Is this doable? I'd like to think so, but have no time for a real test in code.

      Thanks,
      Stefan
        • 1. Re: Building semi-automatic conflict resolution
          Ben Speckhard-Oracle
          Hi Stefan,

          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.

          Regards,
          Ben
          • 2. Re: Building semi-automatic conflict resolution
            Stefan Jager
            Hi Ben,

            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.

            Thanks again,
            Stefan
            • 3. Re: Building semi-automatic conflict resolution
              aschilling
              hi Stefan,

              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 :)

              regards,

              Andreas