Skip to content

Commit

Permalink
conflict detection and resolution documentation
Browse files Browse the repository at this point in the history
  • Loading branch information
chenson42 committed Apr 25, 2012
1 parent 2d75ba6 commit 552445a
Showing 1 changed file with 163 additions and 11 deletions.
174 changes: 163 additions & 11 deletions symmetric/symmetric-assemble/src/docbook/conflicts.xml
@@ -1,13 +1,165 @@
<?xml version="1.0" encoding="UTF-8"?>
<section version="5.0" xml:id="conflicts" xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:ns="http://docbook.org/ns/docbook"
xmlns:mml="http://www.w3.org/1998/Math/MathML"
xmlns:html="http://www.w3.org/1999/xhtml">
<title>Conflict Detection and Resolution</title>
<para>
Blah, Blah, Blah ...
</para>
<section version="5.0" xml:id="conflicts" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:svg="http://www.w3.org/2000/svg" xmlns:ns="http://docbook.org/ns/docbook"
xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:html="http://www.w3.org/1999/xhtml">
<title>Conflict Detection and Resolution</title>
<para> Conflict detection and resolution is new as of SymmetricDS 3.0. Conflict detection is the act of determining if an
insert, update or delete is valid based on whether an incoming data change comes from a source system that was up to
date with the latest changes to the target row. Conflict resolution is the act of figuring out what to do when a
conflict is detected.
</para>
<para>
Conflict detection and resolution strategies are configured in the
<xref linkend="table_conflict" xrefstyle="table" />
table. They are configured at minimum for a specific
<xref linkend="table_node_group_link" xrefstyle="table" />
. The configuration can also be specific to a
<xref linkend="table_channel" xrefstyle="table" />
and/or table.
</para>
<para>
Conflict detection is configured in the
<literal>detect_type</literal>
and
<literal>detect_expression</literal>
columns of
<xref linkend="table_conflict" xrefstyle="table" />
. The value for
<literal>detect_expression</literal>
depends on the
<literal>detect_type</literal>
. Conflicts are detected while data is being loaded into a target system.
<variablelist>
<varlistentry>
<term>
<command>USE_PK_DATA</command>
</term>
<listitem>
<para>Indicates that only the primary key is used to detect a conflict. If a row exists with the same
primary key, then no conflict is detected during an update or a delete. Updates and deletes rows are
resolved using only the primary key columns. If a row already exists during an insert then a conflict
has been detected.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>USE_OLD_DATA</command>
</term>
<listitem>
<para>Indicates that all of the old data values are used to detect a conflict. Old data is the data
values of the row on the source system prior to the change. If a row exists with the same old values
on the target system as they were on the source system, then no conflict is detected during an update
or a delete. If a row already exists during an insert then a conflict has been detected.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>USE_CHANGED_DATA</command>
</term>
<listitem>
<para>Indicates that the primary key plus any data that has changed on the source system will be used to
detect a conflict. If a row exists with the same old values on the target system as they were on the
source system for the columns that have changed on the source system, then no conflict is detected
during an update or a delete. If a row already exists during an insert then a conflict has been
detected.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>USE_TIMESTAMP</command>
</term>
<listitem>
<para>
Indicates that the primary key plus a timestamp column (as configured in
<literal>detect_expression</literal>
) will indicate whether a conflict has occurred. If the target timestamp column is not equal to the
old source timestamp column, then a conflict has been detected. If a row already exists during an
insert then a conflict has been detected.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>USE_VERSION</command>
</term>
<listitem>
<para>
Indicates that the primary key plus a version column (as configured in
<literal>detect_expression</literal>
) will indicate whether a conflict has occurred. If the target version column is not equal to the old
source version column, then a conflict has been detected. If a row already exists during an insert
then a conflict has been detected.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
Conflict resolution is configured in the
<literal>resolve_type</literal>
column.
<variablelist>
<varlistentry>
<term>
<command>FALLBACK</command>
</term>
<listitem>
<para>
Indicates that when a conflict is detected the system should automatically apply the changes anyways.
If the source operation was an insert, then an update will be attempted. If the source operation was
an update and the row does not exist, then an insert will be attempted. If the source operation was a
delete and the row does not exist, then the delete will be ignored. The
<ns:literal>resolve_changes_only</ns:literal>
flag controls whether all columns will be updated or only columns that have changed will be updated
during a fallback operation.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>IGNORE</command>
</term>
<listitem>
<para>
Indicates that when a conflict is detected the system shoudl automatically ignore the incoming
change. The
<ns:literal>resolve_row_only</ns:literal>
column controls whether the entire batch should be ignore or just the row in conflict.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>MANUAL</command>
</term>
<listitem>
<para>
Indicates that when a conflict is detected the batch will remain in error until manual intervention
occurs. The row in error is inserted into the
<xref linkend="table_incoming_error" xrefstyle="table" />
table. In order to resolve, the
<ns:literal>resolve_data</ns:literal>
column can be manually filled out which will be used on the next load attempt instead of the original
source data. The
<ns:literal>resolve_ignore</ns:literal>
flag can also be used to indicate that the row should be ignored on the next load attempt.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<command>NEWER_WINS</command>
</term>
<listitem>
<para>Indicates that when a conflict is detected by USE_TIMESTAMP or USE_VERSION that the either the
source or the target will win based on the which side has the newer timestamp or higher version
number.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</section>

0 comments on commit 552445a

Please sign in to comment.