Enfocus Community

When will the unique prefix roll over? How unique is it?

The unique ID is a five character number in base36, ie it counts from 1 to 9 and then from A to Z before incrementing the next digit. Here are a few lines from the documentation:



For the technically-minded: each of the five characters in the unique name prefix can be a digit (0-9) or an uppercase letter (A-Z). This allows 36^5 or about 60 million combinations. A different unique name prefix can be generated every second for about 23 months.


Freddy

Thank you for the explanation. I might actually need something a little more unique. I guess I'll try a way to generate an MD5 or something similar with scripting.



Thanks!

Can you share why you would need something more unique?



One of the purposes of the unique ID is to make sure that jobs with the same name can be used at the same time (in the same or in different flows). In that respect the unique ID has a temporary nature: in almost all cases the unique ID is stripped after the final processing of the file. It is technically possible to keep the unique ID after the job has been completely processed, but I see no reason to keep it for some sort of archiving purposes.



Side note: keeping the unique ID at the end of a flow is recommended when the end of that flow is the beginning of another flow. In that way all the metadata and properties of the job are kept alive. It is also a good method to still access all that metadata of the job during the design phase of the flow.



You can of course always add a prefix of your own choice to the file name, but internally this prefix will in its turn always be prefixed by a Switch unique ID for the lifetime of the job.



Freddy

Sorry to get in between but I would like to verify your statements regarding the metadata, Freddy:



When I put No on strip unique key at the end of the flow, does this enables me to see the metadata of this file for good?

Yes, but I would not recommend doing that.



Keeping the unique ID is a good idea when jumping from one flow to another, because it keeps the metadata, but at some point in time you have to reach an end where Switch can forget about the job. There is no real database under the Switch hood, and if you keep all jobs that pass through Switch alive for good, I suspect that after a while you will start having performance problems.



Freddy

freddyp wrote: Can you share why you would need something more unique?
I'm tracking jobs between Switch and another system. The jobs will live in some form for many years in the other database and I want that database to have whatever identifier I'm using as a unique. So using Switch's unique ID doesn't seem like a good idea in this case.