Re^2: How to deal with data race issues with Perl?

Replies are listed 'Best First'.
Re^3: How to deal with data race issues with Perl? by ELISHEVA (Prior) on Dec 31, 2010 at 05:48 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^3: How to deal with data race issues with Perl?
by ELISHEVA (Prior) on Dec 31, 2010 at 05:48 UTC

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.

[reply]