Clarification on UUID Format for AR_V_TASK_UUID in Qlik Replicate’s Expression Builder
Hello,
I am currently working with Qlik Replicate and using the expression builder for a project. I came across the AR_V_TASK_UUID variable and need some clarification regarding the UUID format it returns.
Can anyone please confirm the UUID format returned by the AR_V_TASK_UUID variable when used in Qlik Replicate's expression builder? I understand that UUIDs are generally represented in the standard 8-4-4-12 format (32 alphanumeric characters separated by hyphens), but I would like to know if the AR_V_TASK_UUID variable is generated using UUID4 preferably.
Example of a UUID in the standard format:
123e4567-e89b-12d3-a456-426614174000
I would greatly appreciate any insight or information you can provide. Thank you in advance for your assistance!
WHY? What do you intend to use the information for?
Years (many versions) ago, I cloned tasks using (Perl and/or Powershell) scripts. I just dropped the line defining one. When Replicate first starts a task it checks whether it is zero, generates and saves.
Replicate uses a system (linux vs windows) dependend system function to create it. On Windows : CoCreateGuid. The format it expects, is as you show. For example from a task saved as json I have it shows: "task_uuid": "5060efff-a731-cc45-872b-81b7cffa810b" . That's 32 nibbles, 16 bytes formatted using "%02hhx" in groups of 4-2-2-2-6.
There is no practical external use that I can tell. At best you could detect that the taks doing the replication was changed, or when multiple tasks operate to the same target table tell the difference. Please explain why you think it might be useful.
@Heinvandenheuvel , @john_wang , thank you for your response. To answer your “WHY? What do you intend to use the information for?” as you so politely and professionally put it, my intention in asking about the UUID format used by Qlik Replicate was to understand how it is generated and whether it follows best practices for avoiding collisions, as UUID collisions can potentially lead to data loss or corruption. I am trying to implement a change data capture and I was thinking of using it in transformation as a new column like @john_wang mentioned.
However, based on your response, I would like to ask if there is any reason why the format of how the UUID is generated is not meant to be known by external users? If there are any security or confidentiality concerns related to the UUID generation process, I completely understand if the details cannot be shared. Thank you for taking the time to respond to my question.
Hmm, I indicated how the UUID is calculated using the system provided function CoCreateGuid (on Windows). Google that!
Why do you think this is a concern? What indications do you have that this could ever cause dataloss? How would you proposed to control the UUID should there be an issue - which there isn't.
How did you test this yourself? Why did you not test this yourself?
I just cloned a working task into 2, each with different tables to make it easy for now and left the UIID in the JSON for both as "task_uuid": "5060efff-a731-cc45-872b-81b7cffa810b". Took all of 5 minutes to test.
