MODINV-455: Inventory created more Instances records than were in the file

[Aliaksandr-Fedasiuk]

Purpose

Inventory created more Instances records than were in the file because it generates a unique id for each request

Approach

In our distributed system, we can use the unique id already created by another module, since these entities are in the 1-2-1 relationship

Learning

https://issues.folio.org/browse/MODINV-455

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[marcjohnson-kint]

In our distributed system, we can use the unique id already created by another module, since these entities are in the 1-2-1 relationship

Does this mean using the same UUID for the id of two different records (of different record types)?

[Aliaksandr-Fedasiuk]

In our distributed system, we can use the unique id already created by another module, since these entities are in the 1-2-1 relationship

Does this mean using the same UUID for the id of two different records (of different record types)?

yes. these records will not overlap and are located in different schemes, but this decision will accurately block the system from duplicates without additional costs. We can, of course, to add a separate unique field, but this will lead to a new additional complication of the system (writing of new migration scripts, fields in objects, and etc.)

[marcjohnson-kint]

yes. these records will not overlap and are located in different schemes, but this decision will accurately block the system from duplicates without additional costs.

My understanding is that FOLIO chose UUID for it's ID properties so that they would be globally unique and it wasn't intended that the same ID be used for two different records (even if they are different types)

We can, of course, to add a separate unique field, but this will lead to a new additional complication of the system (writing of new migration scripts, fields in objects, and etc.)

I don't know what the specific use case is. If one of the record types relates to the other, I might want that relationship to be made explicit by having a property named for that purpose.

I don't have any authority over this decision, it is for you and your team to make. I only wanted to understand better and share my understanding of prior decisions.

Given this change has been approved already, that suggests folks are happy with it. I won't comment further.

[Aliaksandr-Fedasiuk]

yes. these records will not overlap and are located in different schemes, but this decision will accurately block the system from duplicates without additional costs.

My understanding is that FOLIO chose UUID for it's ID properties so that they would be globally unique and it wasn't intended that the same ID be used for two different records (even if they are different types)

We can, of course, to add a separate unique field, but this will lead to a new additional complication of the system (writing of new migration scripts, fields in objects, and etc.)

I don't know what the specific use case is. If one of the record types relates to the other, I might want that relationship to be made explicit by having a property named for that purpose.

I don't have any authority over this decision, it is for you and your team to make. I only wanted to understand better and share my understanding of prior decisions.

Given this change has been approved already, that suggests folks are happy with it. I won't comment further.

My team agrees with this, but it's good that you point it out. Thank you