Esri Versioning Overview

hi my name is sky Perry with us SP Novation's and I'm here to talk to you today a little bit about one of my favorite topics over the years as REE versioning now this is a topic we've written many many articles on and we've created an e-book that's been released on versioning so it'll get you way more detailed information we're covering today what I wanted to start off with a brief overview of the concept of version it kind of kind of get you started so versioning again all about an ESRI geo database and I assume if you're watching this using ESRI geo database likely that has versions so let's talk about what happens behind the scenes when we use a enterprise to your database with versioning so we're a start off here in Ezra geo database you imagine you're gonna create a new feature class so in our case we're gonna start off and we're going to create a feature class called Electric which is our data owner dot poll now when we create this it creates the table within the geo database a couple other things one of the key things I want to point out though is its firing a update into the table registry or an insert into the table registry which is a table that manages all the other tables and it's basically going to give it an ID so we're going to say the ID in this case is equal to one two three just to keep it simple so we've got an ID one two three is time to electric that poll now this table is not versioned yet we haven't taken that step so the next piece we would do want to talk about is as we register this as version and that's a arccatalog operation let's put version in there when we do that it creates two additional tables as well some other sequences but the two tables I really want to call out to you our first is still electric I'll skip that part on the board here but it's electric and it creates a and uses that same ID here 1 2 3 4 an add table a 1 2 3 the second important table that it creates is called a D 1 2 3 the D is for delete so we now when we talk about the tabe really have three separate tables that we're utilizing in the concept of versioning the base table your Hearst call that the base table is the electric pole we have electric dot a 1 2 3 which is our add table and the D 1 2 3 which is our delete table so we call these to add and delete tables for short now in versioning the concept of version he really runs heavily off of a thing called I'll put in parenthesis down here the state ID so the state ID is used to really manage edits through time so it's very important and each of these tables uses that state ID as new records are added to it so this is the foundation of versioning here we're using the registration ID and the AMD tables and the next thing I want to look at is how do version edits get applied to these tables so we'll actually come over here to the right and I've just simulated here three different edit types which are commonly made the add new record the delete record and the update record and we're gonna talk about them all in the concept of electric pole all right so let's start off there if we add a new record we draw a new record we've created a version to be clear with an arc map we started an in edit session we put a new record onto the map place new pole at that point in time we were actually writing to the a table so we put a simple record in it puts it into the a table not into the base table again because this is a version we have to be able to see what how it existed beforehand so that has not been posted has not been pushed up so just a simple record into the a table now D a delete you can imagine goes pretty much the same way so the delete number 2 comes down here to the D table this allows us with an existing record you imagine we have a pole that maybe already existed up here the D says okay we've deleted that record now both of these guys entered our capturing state IDs within the version entry now our third one gets a little bit more complicated this is a delta change this is a update to an existing record could be an update to that ad we already made could be an update to an existing pull this in the base table but as maybe you're already thinking ahead this update comes in and it first has to put in a delete then it also has to put in an ad so showing hey we deleted the old record we've now added a new version of that wreck so we have two individual records making up that update event now all of those changes could be in a single version and they're maintained as a group of edits again using state IDs this data however is isolated to that version if I go back and look at a new version or maybe at the SD default version I'll talk more about that in a second I'm only seeing the base table or whatever states were already posted up in that case so let's move forward to talk about what happens with these edits as we move forward if you're familiar with versioning you've certainly heard of SDE for spatial database engine that's just the SDE user in your database and we have the default version so this is your top-level version and we had no edits to the system this would be the single source of the truth all edits would be pointed to here and probably right out of our base tables so underneath SDE default in the concert diversion and we have many different edit versions let's just say 1 2 & 3 in this case we'll call this you know this was already edited previously so as we pull these versions they can't see all of those other edits and that's because ste default even though it has a name and all versions have a name at the core points to a state ID that tells us what edits are included so your sync state ID here and you're also seeing state ID in our add and delete stables so these state IDs are really important we have an article dedicated to the state ID because it's so important it's the core of how versioning works so SD default says ok I'm looking at this state ID which edits are included we take the base table and depending on where my state ideas in the point-in-time it'll apply various add records and various delete records to render a view of the data so as you might imagine then progressed through time we have many different versions applying many different edits to our poll feature class these tables here the Delta tables are going to get bigger and bigger and bigger as more edits are applied so the question really then becomes how do edits get from the a and B tables into the base tables because that's really important for the performance of our geo database when I've edited a single version referencing a state ID a set of I will eventually reconcile and post that version up so we're taking a post operation and that post operation is taking the edits from here saying hey make these publicly available now some people say oh when I post it those edits get moved to the base table and that's a common misconception what's really happening here in this post is it just re referencing ste default the public top-level version to a new state ID a stated idea that now includes those edits that have been posted but again other versions may reference an earlier point in time before those versions were there so the state IDs again the core versioning are all lining up but just rear efference is SDU default so how do we get those at its stem the key operations that we have to undertake to get this posted its first a reconcile so we don't have the post offers that's another common misconception to get things to get to the base tables you have to post everything not true what we take here is the edits in this state ID that have been pushed up to sd default and we need to reconcile them down we're gonna reconcile is an ESRI operation most often done through maybe arcmap or maybe through a batch process we reconcile them down to all these one two and three versions and of course you have thousand versions you get them into all thousand versions now when we talk about reconciles and this is a hot topic on its own very important if we have a single version that is unreconciled we don't have a full reconcile across the system if we have a single version that is in conflict right a conflict means that an edit in number three can flex with one of the states I'm trying to pull down from my posted version that will not allow that reconcile to work that basically invalidates a full reconcile even one of those cases in the the hardest part to understand it only takes one if you have a thousand versions in one version in that state tree is not reconciled you're done doesn't matter you got to get them all this is why we have so much on fixing your conflicts as the data is reconciled down on a daily basis to make sure that this is a continuous process you may have conflicts every day but if you resolve them it'll be a moving process that continues moving forward so get that full records out eventually the IDS here this state ID is that those states are reconciled down to all versions in your state tree it invalidates those states and there's only at that point in time that we can come up and run the operation that we call a compress again this can be done in our catalog could be done from the command line or a batch application so the compress effectively looks at the state IDs they're important again state ID don't forget that word takes the state IDs looks for any invalidated states that are no longer needed why because they've been reconciled down to all versions across the state tree as it finds those it can then go look at the a and D tables in our case the pull AMD tables in your case many many more a and D tables and it can take those edits and push them from the a and D tables up to the base table electric pole now again just just to beat the dead horse a little bit if any one version in this state tree has not been reconciled either on purpose or perhaps because it has conflicts those state IDs do not get invalidated now I can run this compress ten times it will not matter it will not affect the state tree why because it has to hold those old states we have not invalidated so again the reconcile operation will invalidate state IDs that allows this to be effective we always say the compress being effective will reduce the count and these AMD tables and therefore will keep my performance in my geo database humming right along very important for all these operations to work in tandem a very complex topic and that's why we have a series of articles and now the e-book coming out on the topic but hopefully this scenario will give you a little bit of an overview and maybe get you a little bit more interested if you're running one of these systems and you are the GIS manager or perhaps a GIS analyst it's one of the most important topics for you to be familiar with ensure your geo database runs effectively that it performs well and that you're ensuring that the data is getting to the right locations so the your geo database works efficiently as possible so thanks for your time today hopefully this helped something like

Channel: SSP Innovations

Views: 14,117

Rating: 4.9018407 out of 5

Keywords: ArcGIS Online, Esri, ArcGIS, ArcGIS Server, ArcFM, Geographic Information System (Industry), Utility Cooperative (Business Operation)

Id: WrsfjNF4zCQ

Length: 11min 19sec (679 seconds)

Published: Wed Nov 04 2015