Are Global IDs necessary for Attribute Rules?

1490
7
05-27-2021 06:25 AM
DanielRoth
Esri Contributor

I read it is mandatory to have Global IDs in order to use Attribute Rules, is it? And why is that? I found no explanation in the docs.

Also read my question here please: Are Global ID preserved by the platform? - Esri Community

Thank you

7 Replies
JoeBorgione
MVP Emeritus

Can't tell you why but yes, for attribute rules to function your feature layer must have global ids.

That should just about do it....
HusseinNasser2
Esri Contributor

You will start seeing the reliance of GlobalId in the new built system as a globally unique identifier instead of the object Id. Utility Network, Version Management, Sync, and yes Attribute rules. The systems become so tightly integrated together it is just easier to always require globalId so those system can interact with each other effectively.

For attribute rules and validation and batch calculation in particular, we persist globalId of the source feature in the validation error tables. We also display the globalId of the feature that failed a constraint rule.

And to answer the question, globalIds are not preserved by default when transferring data, you will have to make sure its preserved by checking that box. It is not on by default so that it doesn't break old workflows.

 

For instance you have to preserve GlobalIds in the case of utility network because those globalids are referenced everywhere, but you don't necessarily have to preserve the GlobalId for tables with attribute rules

TomNeerDDS
New Contributor

With the migration to GlobalIDs is there any plans to implement GlobalIDs as a true primary key in FGDBs? Currently, FGDB GlobalIDs do not support UNIQUE nor NOTNULL constraints. I support any replacement the 1980s ObjectID with either a UUID(4) or SERIAL(8) datatype.

I actually tripped over this the other day. "Preserve Global IDs" does not work with FGDBs. It only provides a message to build a new index with UNIQUE enabled but does not tell you it is unsupported in FGDB, nor does the "Add Attribute Index" command. After a couple hours of head scratching found a sentence buried in the documentation that they are unsupported.

While it is possible to enforce UNIQUE and NOTNULL constraints using Arcade, this seems extremely inefficient for something that should be supported by FGDB. Right now, just writing GlobalIDs to GUID fields to make a permanent copy. Also inefficient but better than the alternative that I could figure out.

0 Kudos
JoeBorgione
MVP Emeritus

Take a look at using geodatabase sequences.

They work great and are simple to deploy.

That should just about do it....
0 Kudos
TomNeerDDS
New Contributor

Thanks for the quick response, but this is not the issue. Attribute Rules require GlobalIDs, not a sequencer.

0 Kudos
JoeBorgione
MVP Emeritus

Having re-read your post, I apologize. I’m afraid I don’t understand the meaning of a ‘true primary key’.

That should just about do it....
0 Kudos
TomNeerDDS
New Contributor
A primary key must have two constraints on it. It must be unique and it must be not null. In a FGDB, the only datatype this seems true for is an ObjectID. There is no way that I can discern that this can be done on a GlobalID in a FGDB. Which means a GlobalID can be null and not unique. Not a good primary key.

I am interested because if I assign a GlobalID is a FGDB, I now have to test for not null and unique. If GlobalIDs are going to replace ObjectIDs, this needs to be fixed, hence my question to Hussein.

I wholeheartedly support the migration from ObjectIDs to GlobalIDs. The sooner the better. Esri software is the only database left that I use INT4 sequencers. It's time to let the 1980s go and move to modern datatypes. 😃
0 Kudos