What are implications to R&H Oracle systems with regards to branch versioning?

Discussion created by Scott.Fierro on Aug 21, 2019

Not sure if anyone else is the "reads ahead" sort. I was reviewing something that an ESRI employee on the database side I am familiar with sent out regarding the excitement around branch versioning. It's true there's some great things it opens up and I can see potential opportunities with using it. You can read about it all in these 2 articles:


Intro to Branch Versioning

Setting the Stage


In my typical fashion it's not just enough to get the highlights reel and I had to go under the hood. In there you will find some very interesting gotcha's on the Oracle side. The inability to use compressed tables probably isn't ideal to some of your DBA's but is still acceptable. The inability to use Oracle's native geometry type is what will be cause for concern. If you are like us, we have a slew of other systems that aren't ESRI driven and that utilize the native SDO_GEOMETRY. While it's not a show stopper and you could run everything in ST_GEOM and convert over once you are ready to push standardized data formats across the agency, if you are leveraging Roads & Highways and already scaled out in production using the SDO_GEOM it might get interesting.


I don't know if R&H will eventually leverage branch versioning or not.

I don't know if ESRI intends to eventually have branch versioning work with SDO_GEOM or not.

I can say it's something worth keeping on the radar and it could sway decisions you make for R&H moving forward, particularly once you decide to undertake the move to Pro which seems like the ideal time to stage yourself as best as possible for these types of long-term capabilities.


Here is the article you want to review if you are getting under the hood:

Register Data as Versioned