I am using ArcGIS 9.3.1 and attempting to work with an SDE geodatabase (with one polygon feature class) that has already been registered as versioned. I'm new to versioning and am still trying to figure out some of it's basic functions. So far, I haven't been able to discover if it is possible to "cancel" or "reject" certain edits once they've been posted to a parent version.
For example, let's say we have three versions: the original SDE.DEFAULT that was created when it was registered as versioned, a child version of the default called SDE.QA (for Quality Assurance), and a child version of the QA called SDE.Edit1 (where the edits first take place). If certain features of SDE.Edit1 were edited (e.g., to keep it simple, let's say one polygon was added and one was removed) and then SDE.Edit1 was reconciled with the SDE.QA and subsequently posted to SDE.QA, would there be any way to later undo this change? Following up on this question, would it possible to reject only some changes? For example, accepting adding the first poly, but rejecting removing the second poly?
As far as I can tell, once edits have been posted to the parent version, all these changes are now a "permanent" (for lack of a better word) part of the parent version. I am aware of the fact that these changes are all recorded within two tables, the "ADD" and "DELETE" tables (often referred to as the "delta" tables), and don't actually change the original FC itself. I considered looking into manually altering these delta tables, but I found enough people warning against that to know that it's likely not the right solution.
Perhaps it is my understanding of versioning that needs some work, but I couldn't seem to find a way to reject a change or undo a change once it's been posted. This seems strange to me, as this would mean that there is no way to undo a post which contained an error. I also can't seem to find a way to trace the lineage of these versions (i.e., which version is the child of which parent). While I'm on the topic, if anyone might know of any particularly useful ArcSDE references (links, articles, books, etc) that might help with my understanding of ArcSDE (and perhaps answer some of these questions), it would be much appreciated!
Although answers so far have been helpful (thank you for the links), I still cannot find an answer to the core of my question. Again, perhaps it is my own misunderstanding of the situation. Here is what I want to know:
Can you reverse (by reverse, I mean undo) a post once it has been made from a child version to a parent version? In this scenario, the parent can be, but doesn't have to be, the SDE.DEFAULT version. Even better, I would like to know if you can reverse a part of a post (say, a single edit to a polygon), after it has been posted? I would also like to know if this can be done without the need to have had any conflicts detected.
The fact that I can't find a clear answer to this question (i.e., "yes" or "no") documented anywhere makes me think I am missing something important about versioning in the ArcSDE. I would also prefer to avoid manipulating the A and D tables manually.
Answer
Ugh. The answer is really a complicated one that requires a lot of ArcSDE background, so I will try to be as brief as possible.
Note I am going to refer to some diagrams from the super awesome versioning white paper that you can find in the ESRI site. If you are dealing with versioning, I extremely encourage you to read it throughly.
Then, you need to understand what is the relationship between a state (i.e a node from the state tree) and a named version (i.e a label pointing to a state).
A typical database may look like the state-diagram below:
Here, you have four versions in the database (Version A, Version B, Version C and DEFAULT). But perhaps, I am getting a little ahead of myself. Let's start with what a state is.
You can think of a state as a "transaction" - a logical unit that contains several edits to one - or many - tables. It may include two inserts to "FeatureClass A", a delete from "Feature Class B" and a modify (effectively a delete + an insert) to "Feature Class X". All grouped into one.
Let's look at a small, simple, ArcSDE state diagram that starts at state id 0:
If you start at state 0 and you do edits to one or many tables in an edit operation, you will create a child state 1 and make that one the current active state id. Another subsequent group of edits will create child state 2. If you want to undo, you don't need to modify the state id in any way - all you need to do is change the current active state id to 1, or 0 (depending how far back you want to go). A redo is the opposite - just move the current active state id forward - as far forward as you want to go.
That is how undo/redo works in ArcSDE versioning.
OK, moving on. Say, that you want to make an edit permanent (i.e, you want to save). What do you have to do? Well, saving is just grabbing a version label and moving it forward to a particular state. Kind of like stamping it and saying "this is what Version A must look like". So if you look back at the first diagram, you will see that it has four named versions.
- Version B points to state id 1
- Version A points to state id 3
- Version C points to state id 5
Version "SDE.DEFAULT" points to state id 4
Please note that this diagram, despite popular belief, does not tell you anything about the logical parent-child relationship that they have. The logical parent-child relationship for the first diagram could effective look like this:
This is the parent-child relationship that you see in ArcMap/ArcCatalog. It's purpose, is to restrict which versions you can reconcile against. At this point, you could (rightfully) be asking yourself, why the hell do I need this? The answer, lies in versioning workflows. Turns out, people have been using versioning for quite some times and there are some preferred ways of how to structure these, but that is a topic for another day since I want to answer your question today :)
Moving on...
OK, so what else do this named versions do? Well, they affect how this process called compress behaves.
Compress is all about grabbing intermediate states that may not be necessary, and removing unnecessary ones as well as combining them. You can trigger the ArcSDE compress operation through ArcCatalog, setup a service that does it every one in awhile, and some ArcMap edit operations will trigger mini-compress operations (i.e just for small branches that are being used).
The diagram on the left shows a state tree before it gets compressed, and the one on the right shows it right after it gets compressed:
An important concept to understand (which I will refer to you once I finally get to answer your question) is that every single state is a potential candidate to be compressed - except states that have labels (i.e named versions) pointed at them.
You can see that before the compress there are some extra - unnecessary states. In fact, the entire [3,4,5] branch got removed. Had there been a named version at 5, the end result would have been very different.
Compress operations are there to save space on your database by removing records you do not need anymore.
OK, moving on.
The last concept that you need to understand, is reconciling - which is effectively merging two branches into one.
So let's go back to our very first diagram. Say that you want to reconcile Version A against SDE.DEFAULT.
Let's recap: four named versions pointing to various state ids. So the first thing that we have to do, is create a child state under the target version, so we create a child state under state id 4, in our example, I call that state id 20.
The next step is to calculate the differences between both versions (the details are too long for this post, but I can tell you that they are done with difference cursors) and then applying those differences to that new state id 20 (blue line).
Say that you decide to do more edits or that you found conflicts and are choosing rows from one version, or the other. It doesn't matter. Those are just new edits, and are done inside an edit operation, as child states underneath the branch that you merged. In this example, I have done two more consecutive group of edits after the reconcile.
Lovely.
So now say that you are ready "post" the version. What does that mean? That is just grabbing the labels and pointing them to the same state id. Here, I am going to post Version A to SDE.DEFAULT. This is what it looks like:
TADAAA! So now Version A and SDE.DEFAULT are pointing to the same state id, and thus they look the same.
OK, so now I can finally answer your question.
Can you undo a post? The ArcGIS documentation will tell you no - don't mess with it. Don't do it, because you will be messing with this logic, and if you don't know what you are doing, you can corrupt your data.
But in truth, all it takes is to do one update of one of the ArcSDE Versioning tables - the VERSIONS table, and modify the entry of the label (aka named version). In our example, point to state id 21, and you have just undone that entire edit operation. Set it to 3, and you just undid the entire reconcile. Set it to 5, and now you are in a completely different place. Whether there are or there are not conflicts is irrelevant.
Of course, this assumes that a compress has not happened. Let's consider the case where the compress is happening right at the exact same time you are updating the SDE table. Remember, if you - or somebody else - executes a compress after you posted this is what the tree looks like:
Can you undo the reconcile after the compress? Well, in this case, no. The compress has blown away that entire branch, so you cannot undo - that data has been removed. Had there been another named version on that branch, then the compress would not have destroyed that branch. I hope that by now this makes sense.
So should you do this? Up to you, if you don't know what you are doing, you can easily loose data after a compress.
No comments:
Post a Comment