Persistent IDs vs. Persistable IDs

Important News:  Before I get into this article, there are some hotfixes you will want to get if you are going to use persist(ent/able) IDs.  If you are already using these IDs and have replicated Vault database servers, you need to check those IDs to make sure they are valid.

Hotfix links:

• Vault 2014 SP2
• Vault 2014 SR1, SP1 (subscription center only)
• Vault 2015

Once again, the API contains two different things that are almost spelled the same  (Naming scheme and numbering scheme, I’m looking at you).  This time around it’s Persistent IDs and Persistable IDs.  These two things are almost the same, but API’s don’t understand “almost”.  If it’s not exactly the same, it’s invalid.  There is no in-between.

I’ve already written about persistent IDs, so you can give that a read if you want to know about the concept.  Persistable IDs are the same thing except those IDs have an extra character in from of them.  No, I’m not making that up.

An “m” is put on the front if the Persistable ID is not version specific.  A “v” is put on the front if the ID to a specific version.  The “m” stands for Master, in case you are wondering.  Like how a FileMasterId is the same for all versions of a file.  Anyway, the rest of the ID is the same as the Persistent ID.  So you can easily convert from one to the other by adding or removing the character at the front.

The other difference between the two ID types is where they are found at the API.  Persistent IDs are at the web service layer, in the KnowledgeVaultService.  Persistable IDs are in the VDF layer, in Connection.PersistableIdManager.

Sure, it would be nice if we could consolidate these two types, but that would require one of them to change.  And the entire point of these IDs is that they can’t ever change.  So were stuck with these two.  If you use one to store data, just make sure you remember which type of ID you used.

To summarize: