topic Re: Conflict definition/conflict resolution concept, in Data Management Questions

Conflict definition/conflict resolution concept,

JamalNUMAN — Sun, 29 Sep 2013 19:36:09 GMT

Conflict definition/conflict resolution issue,

As I understand, the conflict resolution states which database is determinant in case of conflict. What I couldn�??t figure out is the impact of conflict definition (by object/by attribute).

Scenario:

1. I have the sde.default and u1.u1 version

[ATTACH=CONFIG]27858[/ATTACH]

2. The sde.default and u1.u1 are updated (feature #9 is updated spatially and by attribute as shown below)

[ATTACH=CONFIG]27859[/ATTACH]

3. The reconcile/post is applied is applied where the conflict resolution is set to be �??favor_target_version�?� which means that the updates (spatial/attribute) of sde.default replaces their corresponding values of u1.u1. the conflict resolution is set to be "by object"

[ATTACH=CONFIG]27860[/ATTACH]

4. The result is shown in the screenshot below (both location and attributes are updated based on the sde.default)

[ATTACH=CONFIG]27861[/ATTACH]

What I couldn�??t understand is the impact of setting the conflict definition to be by object or by attribute. In these two cases, the result is the same. Both spatial location and attribute values are updated

What is significant about the conflict definition (by object/by attribute)? where its impact can be felt?

Thank you

Best

Jamal

Re: Conflict definition/conflict resolution concept,

Anonymous User — Mon, 30 Sep 2013 08:47:40 GMT

Original User: mboeringa2010

Conflict definition/conflict resolution issue,

As I understand, the conflict resolution states which database is determinant in case of conflict. What I couldn�??t figure out is the impact of conflict definition (by object/by attribute).

Just to make sure you don't misunderstand this: in the end, it is always you as a user who needs to determine which state of an object is the right one, and needs to be maintained. Even if you set an (automated) option, like "in favour of target", you are making an important decision, namely to always favour the target! You really need to consider if you want automated reconcilation or not, and this determines your workflow setup. You may need to have manual intervention by someone with authority to determine which state is right.

What I couldn�??t understand is the impact of setting the conflict definition to be by object or by attribute. In these two cases, the result is the same. Both spatial location and attribute values are updated

What is significant about the conflict definition (by object/by attribute)? where its impact can be felt?

Another thing you really need to understand fully is, that by definition, any reconcilation will always lead to fully identical features on both the parent and child. This means that BOTH the geometry AND all its attributes will be exactly the same. The reason for this is that, after reconcilation and post, the two features will point to the same database state. This means that it is absolute impossible to have two features not being fully identical, because both features from the parent and child version are pointing to exactly the same database record!

If you set "BY_ATTRIBUTE", you are just telling ArcGIS to automatically and silently merge attributes updates to two or more different fields, and to not flag them as a conflict.

E.g., if you initially have feature A in the parent with a value of "Oak" for the field "Tree_species" and "30 years" for field "Tree_age", and the tree species in the parent is updated to read "Birch", while the tree age is updated in the child to be "40 years", than the resultant feature will have "Birch" and "40 years" after reconciliation in both parent and child. See below.

BEFORE EDITS
Parent
"Tree_species":"Oak"
"Tree_age":"30 years"

Child
"Tree_species":"Oak"
"Tree_age":"30 years"

AFTER EDITS
Parent
"Tree_species":"Birch" (EDIT!)
"Tree_age":"30 years"

Child
"Tree_species":"Oak"
"Tree_age":"40 years" (EDIT!)

AFTER RECONCILIATION (no conflict detected with option "BY_ATTRIBUTE"~~!)
Parent
"Tree_species":"Birch"
"Tree_age":"40 years"

Child
"Tree_species":"Birch"
"Tree_age":"40 years"

As you can see, both edits are silently merged without a conflict being raised, because the attribute changes in parent and child are on different fields and can be merged without causing an inconsistency.

Re: Conflict definition/conflict resolution concept,

JamalNUMAN — Mon, 30 Sep 2013 21:42:55 GMT

Just to make sure you don't misunderstand this: in the end, it is always you as a user who needs to determine which state of an object is the right one, and needs to be maintained. Even if you set an (automated) option, like "in favour of target", you are making an important decision, namely to always favour the target! You really need to consider if you want automated reconcilation or not, and this determines your workflow setup. You may need to have manual intervention by someone with authority to determine which state is right.

Another thing you really need to understand fully is, that by definition, any reconcilation will always lead to fully identical features on both the parent and child. This means that BOTH the geometry AND all its attributes will be exactly the same. The reason for this is that, after reconcilation and post, the two features will point to the same database state. This means that it is absolute impossible to have two features not being fully identical, because both features from the parent and child version are pointing to exactly the same database record!

If you set "BY_ATTRIBUTE", you are just telling ArcGIS to automatically and silently merge attributes updates to two or more different fields, and to not flag them as a conflict.

E.g., if you initially have feature A in the parent with a value of "Oak" for the field "Tree_species" and "30 years" for field "Tree_age", and the tree species in the parent is updated to read "Birch", while the tree age is updated in the child to be "40 years", than the resultant feature will have "Birch" and "40 years" after reconciliation in both parent and child. See below.

BEFORE EDITS
Parent
"Tree_species":"Oak"
"Tree_age":"30 years"

Child
"Tree_species":"Oak"
"Tree_age":"30 years"

AFTER EDITS
Parent
"Tree_species":"Birch" (EDIT!)
"Tree_age":"30 years"

Child
"Tree_species":"Oak"
"Tree_age":"40 years" (EDIT!)

AFTER RECONCILIATION (no conflict detected with option "BY_ATTRIBUTE"~~!)
Parent
"Tree_species":"Birch"
"Tree_age":"40 years"

Child
"Tree_species":"Birch"
"Tree_age":"40 years"

As you can see, both edits are silently merged without a conflict being raised, because the attribute changes in parent and child are on different fields and can be merged without causing an inconsistency.

Thank you very much Marco for the help,

Based on valuable elaboration you have already provided, is it correct to say:

1. If the conflict definition is set to be �??by object�?� then only spatial changes applied to the same FEATURE (in the parent and child) will be considered as conflict and will be flagged for further work. In this case, attribute changes applied to the same record FEATURE (in the parent and child) will never be considered as conflict.

2. If the conflict definition is set to be �??by attribute�?� then only tabular data changes applied to the same RECORD (in the parent and child) is considered as conflict and will be flagged for further work. In this case, spatial changes applied to the same FEATURE (in the parent and child) will never be considered as conflict

I got a question in my mind: when then there is no option to set �??by object�?� and/or �??by attribute�?� at the same time so that the system will flag spatial or tabular changes as conflicts instead of considering one of them ata a time as conflict?

Re: Conflict definition/conflict resolution concept,

Anonymous User — Tue, 01 Oct 2013 10:49:01 GMT

Original User: mboeringa2010

Based on valuable elaboration you have already provided, is it correct to say:

1. If the conflict definition is set to be �??by object�?� then only spatial changes applied to the same FEATURE (in the parent and child) will be considered as conflict and will be flagged for further work. In this case, attribute changes applied to the same record FEATURE (in the parent and child) will never be considered as conflict.

2. If the conflict definition is set to be �??by attribute�?� then only tabular data changes applied to the same RECORD (in the parent and child) is considered as conflict and will be flagged for further work. In this case, spatial changes applied to the same FEATURE (in the parent and child) will never be considered as conflict.

NO (for both questions).

You are misinterpreting what I am saying.

The confusing part is the use of the word "object" in the BY_OBJECT argument. Object is not meant to reference the spatial feature stored in the geometry column, it is meant to refer to the entire record, that is, BOTH the geometry and attribute fields.

With BY_OBJECT, all changes to any geometry or attribute field of the same database record (NOTE 1, see below) will be flagged as a conflict. It essentially means that two editors can not edit the same record, without ArcGIS flagging it as a conflict upon reconciliation.

When you use BY_ATTRIBUTE, two editors CAN edit the same record without causing a conflict, however, only as long as they edit different fields.

See the example in my previous post where the editor of the parent version changed the field "Tree_Species" to "Birch", while another editor changed the field "Tree_Age" to "40" in the child version. These edits were merged silently upon reconciliation, without raising a conflict. In essence, BY_ATTRIBUTE relaxes editing constraints, allowing you to have multiple editors making edits to different fields, without the extra burden of generated conflicts. If the editor of the parent had changed the field "Tree_Age" as well, and had set it to for example "50", than reconciliation with BY_ATTRIBUTE would have generated a conflict as well, just as with BY_OBJECT.

Although this may sound attractive, you should use it with caution, because it will also mean edits done by multiple users to the same records will be automatically and silently merged. If your workflow instead requires consistent "single user" - bad wording here, since you're still in the versioned editing workflow - editing against entire objects / records, than you need BY_OBJECT.

Be aware though, that BY_OBJECT doesn't prevent multiple users from editing the same records (remember we're talking about versioning, so by definition multi-user editing), but it will flag two edits on the same object / records as a conflict. So you still have all reconcilation options allowing you to chose which representation (parent or child), is the right one.

Also see this Help page:
Reconcile Versions (Data Management)
and especially the topic "conflict_definition" there

*** NOTE 1 ***
I would probably better say "object" here, instead of "database record", as the edits to the child version are of course stored in the A/D delta tables, so in reality are in different database records compared to parent before reconciliation. It is the identical OBJECTID that determines which records in the A/D delta tables representing the child version edits, are related to the parent version.

Re: Conflict definition/conflict resolution concept,

JamalNUMAN — Tue, 01 Oct 2013 18:50:22 GMT

NO (for both questions).

You are misinterpreting what I am saying.

The confusing part is the use of the word "object" in the BY_OBJECT argument. Object is not meant to reference the spatial feature stored in the geometry column, it is meant to refer to the entire record, that is, BOTH the geometry and attribute fields.

With BY_OBJECT, all changes to any geometry or attribute field of the same database record (NOTE 1, see below) will be flagged as a conflict. It essentially means that two editors can not edit the same record, without ArcGIS flagging it as a conflict upon reconciliation.

When you use BY_ATTRIBUTE, two editors CAN edit the same record without causing a conflict, however, only as long as they edit different fields.

See the example in my previous post where the editor of the parent version changed the field "Tree_Species" to "Birch", while another editor changed the field "Tree_Age" to "40" in the child version. These edits were merged silently upon reconciliation, without raising a conflict. In essence, BY_ATTRIBUTE relaxes editing constraints, allowing you to have multiple editors making edits to different fields, without the extra burden of generated conflicts. If the editor of the parent had changed the field "Tree_Age" as well, and had set it to for example "50", than reconciliation with BY_ATTRIBUTE would have generated a conflict as well, just as with BY_OBJECT.

Although this may sound attractive, you should use it with caution, because it will also mean edits done by multiple users to the same records will be automatically and silently merged. If your workflow instead requires consistent "single user" - bad wording here, since you're still in the versioned editing workflow - editing against entire objects / records, than you need BY_OBJECT.

Be aware though, that BY_OBJECT doesn't prevent multiple users from editing the same records (remember we're talking about versioning, so by definition multi-user editing), but it will flag two edits on the same object / records as a conflict. So you still have all reconcilation options allowing you to chose which representation (parent or child), is the right one.

Also see this Help page:
Reconcile Versions (Data Management)
and especially the topic "conflict_definition" there

*** NOTE 1 ***
I would probably better say "object" here, instead of "database record", as the edits to the child version are of course stored in the A/D delta tables, so in reality are in different database records compared to parent before reconciliation. It is the identical OBJECTID that determines which records in the A/D delta tables representing the child version edits, are related to the parent version.

Thank you Marco for the very informative answer. This is really helpful.

I hope I�??m accurate this time in re-stating what I have understood from you valuable elaboration

1. The issue of conflict definition merely refers to what the system considers as conflict or doesn�??t and has no impact on the reconcile/post

2. �??by object�?� (feature/record) considers edits (from multiple versions) occurring on the same feature (spatial change such as: move/reshape/delete) AND/OR on the same record (not necessarily the same CELL of a particular field) to be a conflict

[ATTACH=CONFIG]27936[/ATTACH]

3. �??by attribute�?� (cell) considers ONLY edits (from multiple versions) occurring on the same Cell (of particular field/record) to be a conflict and thus �??by attribute�?� is just a special case of the �??by object�?� and limits

[ATTACH=CONFIG]27937[/ATTACH]

Am I correct now?

Re: Conflict definition/conflict resolution concept,

Anonymous User — Wed, 02 Oct 2013 06:09:57 GMT

Original User: mboeringa2010

2. �??by object�?� (feature/record) considers edits (from multiple versions) occurring on the same feature (spatial change such as: move/reshape/delete) AND/OR on the same record (not necessarily the same CELL of a particular field) to be a conflict

3. �??by attribute�?� (cell) considers ONLY edits (from multiple versions) occurring on the same Cell (of particular field/record) to be a conflict and thus �??by attribute�?� is just a special case of the �??by object�?� and limits

Am I correct now?

Although you use different words, and it took a bit of time for me to understand what you wanted to say with your screenshots, I think I can now say:

2) and 3): YES, you do seem to understand it now. I like the way you write that BY_ATTRIBUTE is a special case of BY_OBJECT, because I can see it may help in thinking of it in this way to better understand it.

1. The issue of conflict definition merely refers to what the system considers as conflict or doesn�??t and has no impact on the reconcile/post

YES and NO. It is a bit like asking whether a doorbell of a house has any function. Now it wouldn't be there, if it hadn't a function, would it? The same holds for this option in the automatic process represented by the Reconcile Versions geoprocessing tool. So although you are right the BY_OBJECT and BY_ATTRIBUTE arguments influence what "... the system considers as conflict ...", it does also have impact on the reconcile / post process. By the way, as a side note, please note that in some other parts of the interface, BY_OBJECT and BY_ATTRIBUTE are referenced as ROW and COLUMN respectively. See for example the Help page Reconciling a version.

Look again at the example I gave in post no. 2. Notice that with BY_ATTRIBUTE, the edits made to the target version (parent) and the edit version (child) are automatically and silently merged. With merged, I mean that both edits to the parent and child remain / are represented in the target parent version. No edits are lost.

Now what would happen if we chose "In favour of target" with BY_OBJECT?

Things would be different after a full reconciliation and post. Please note that in this example edits to a single feature / object with one unique OBJECTID are assumed!:

- First, a conflict would be detected:

BEFORE EDITS
Parent
"OBJECTID":"xxx"
"Tree_species":"Oak"
"Tree_age":"30 years"

Child
"OBJECTID":"xxx"
"Tree_species":"Oak"
"Tree_age":"30 years"

AFTER EDITS
Parent
"OBJECTID":"xxx"
"Tree_species":"Birch" (EDIT!)
"Tree_age":"30 years"

Child
"OBJECTID":"xxx"
"Tree_species":"Oak"
"Tree_age":"40 years" (EDIT!)

RECONCILIATION
*** Conflict raised with BY_OBJECT/ ROW as argument! ***
Both target and edit version have an edit to the same feature / object:

Parent:
"OBJECTID":"xxx"
"Tree_species":"Oak" ---> "Tree_species":"Birch"
Child:
"OBJECTID":"xxx"
"Tree_age":"30 years" ---> "Tree_age":"40 years"

- Secondly, the edits in the child or "edit version" would be dropped for the specific conflict case, as the user choose "in favour of target":

AFTER RECONCILIATION AND POST (in favour of target!)
Parent
"OBJECTID":"xxx"
"Tree_species":"Birch"
"Tree_age":"30 years"

Child
"OBJECTID":"xxx"
"Tree_species":"Birch"
"Tree_age":"30 years"

Now notice the difference with the results compared to post no. 2, instead of reading "Birch" and "40 years", both parent and child now read "Birch", "30 years".

Re: Conflict definition/conflict resolution concept,

DerekLaw — Thu, 03 Oct 2013 05:30:15 GMT

Hi Jamal,

FYI, this ArcUser technical article provides a good background on the fundamental concepts of versioning in ArcSDE geodatabases,

Versioning 101

... As I understand, the conflict resolution states which database is determinant in case of conflict. What I couldn�??t figure out is the impact of conflict definition (by object/by attribute). ...

From the article,

"When performing a reconcile operation, ArcGIS finds conflicts in one of two ways: by object ID or by attribute. Conflict by object ID means that a feature is identified to be in conflict when any part of it (e.g., geometry or attributes) has been edited in both the target and edit versions. Conflict by attribute means that a feature is identified to be in conflict only when the same attribute (e.g., the same attribute field) has been edited in both the target and edit versions."

Hope this helps,