I think his suggestion was offered in the spirit of raising additional design issues for consideration. Does the client need only the merged view or both a history of changes and the merged view? It affects how the resync process is carried out and what data is stored after it is done.

Full audit trails (who wanted to make what change when) are a legal and liability necessity in certain accounting and legal/corporate document editing systems. The OP has not stated the nature of the data nor the business process.

Secondly, he is proposing an architecture that allows separation of concerns - (a) the making and tracking of changes (b) the merging of changes into a cohesive view. If each separate change request is recorded, the algorithm for merging them can be changed over time based on developing user requirements.

Separation of concerns can make this an attractive base architecture when the user's requirements are in flux due to an internal learning curve for the business process in question or when needs are liable to change due to a fast changing business environment. On the other hand, it costs more to implement and increases data storage demands, so a base requirement for an audit trail in addition to the merged view is probably in order before pursuing such a design.

In reply to Re^3: How to deal with data race issues with Perl? by ELISHEVA
in thread How to deal with data race issues with Perl? by halfbaked

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.