Menu

Conflict resolution by create_time of the sym_data table

Help
EmirLima
2015-03-05
2015-04-04
  • EmirLima

    EmirLima - 2015-03-05

    In my scenario I have 1 Master node and multiple client nodes.

    Some tables, such as 'customer', are constantly handled by all the nodes (both master and clients) and they need to be always synced.

    I have noticed that the prevalence of updates on the same row by two different nodes in close moments obay always a fixed order.

    Example 1:

    Node 2 updates a customer name to "A" at 10:25:00
    Node 3 updates the same customer to "B" at 10:25:01

    Result: All nodes with the "A" value.


    Example 2:

    Node 3 updates a customer name to "C" at 10:25:00
    Node 2 updates the same customer to "D" at 10:25:01

    Result: All nodes with the "D" value.


    In every conflict betweem Node 2 and Node 3, the Node 2 always win, independently of the time the updates happened.

    Is there a way to tell symmetric to choose the most recent update considering the time in the 'create_time' of the 'sym_data' table?

     
  • Chris Henson

    Chris Henson - 2015-03-07

    sym_data.create_time isn't passed along to the client. The best you could probably do is add a create_time column at your server and use external_select on sym_trigger to populated sym_data.external_data. This could be referenced in an extract transform to get the create_time. Not that simple.

     
  • EmirLima

    EmirLima - 2015-03-16

    I tried this:
    - Add a column 'last_update_time' in my table
    - Set up a conflict with USE_TIMESTAMP, NEWER_WINS, RESOLVE_CHANGES_ONLY for this column

    When two nodes updates the same column in the same row, the conflict is resolved by the last update, as I wanted.

    The problem now is when two nodes updates different columns in the same row. The Symmetric should not be identifying this situation as a conflict but simply merge the two updates. But it's overwriting all the row by the last update.

    The RESOLVE_CHANGES_ONLY flag doesn't act this way?

     
  • Chris Henson

    Chris Henson - 2015-04-04

    It looks like that should work. Is maybe the capture of old_data turned off?

     

Log in to post a comment.