Duplicated UUID primary key with another one existing

Support
#1

Hi, forum followers
First of all, here it is the platform used:

  • CUBA Platform version: 7.2.11
  • CUBA Studio plugin version: 15.1-202
  • IntelliJ version: CUBA Studio 2020.2
  • Sql Server 2008 R2

The problem encountered is the following:
Entities on my project have primary key of UUID type. CRUD operations worked fine on the test environment with Cuba application, without legacy data.
We’ve just migrated legacy application’s data to the new cuba application’s database with SQL Server stored procedures, because data model from one to the other is completely different, achieving the UUID value for every UUID primary key with next PL/SQL commands:

CREATE TABLE #Auxiliar (
		id uniqueidentifier,
		data datetime)
	DECLARE @Auxuuid TABLE (MytempId uniqueidentifier)
	ALTER TABLE #Auxiliar ADD CONSTRAINT Axiliar_ID DEFAULT (newsequentialid()) FOR id
........
INSERT INTO #Auxiliar (data) OUTPUT inserted.id INTO @Auxuuid VALUES(SYSDATETIME())
SELECT @uuidinserit = MytempId FROM @Auxuuid 
insert into MAGATZEM_UBICACIO(ID,UBICACIO_ID, CREATE_TS, VERSION, MAGATZEM_ID) values(@uuidinserit , @ubicacio, SYSDATETIME(),1, @uuidmag)

Now, when testing new Cuba application with a record insertion, next error appears:
imatge

Which is the best way to create UUID primary keys in the data migration process to assure that Cuba application doesn’t assign an UUID value that already exists?. Is there another aspect to have in mind?

Thank you in advance

#2

Hi,
The data on the screenshot is different from your source code.

The table name is different (MAGATZEM_MOVIMENT).
And the conflicting primary key value doesn’t look like UUID: 207.

P.S. Regarding actual question.
UUID generation is using such algorithm that you should meet with UUID duplication very rarely. But when you meet such situation, you don’t have other choice than re-try transaction (retry object creation).

#3

Hi, Alex.

You’re completely right. Sorry.

Parent class for MAGATZEM_MOVIMENT entity is BaseLongIdEntity.
In that case, the solution would be updating the current value of the sequence implemented on SEC_UN_{domain} table to the last value generated with data migration process. Isn’t it?

Regards.

#4

Yeah, I think so.

1 Like