[MODINVSTOR-495] Duplicate UUID in reference data Created: 11/May/20  Updated: 27/Aug/20

Status: Open
Project: mod-inventory-storage
Components: None
Affects versions: None
Fix versions: None

Type: Tech Debt Priority: P3
Reporter: Wayne Schneider Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint:
Development Team: Prokopovych

 Description   

The UUID f5cc2ab6-bb92-4cab-b83f-5a3d09261a41 is used for both the "multipart monograph" modes-of-issuance record and the "not yet assigned" instance-statuses record. At this time, having a duplicate UUID in those places is confusing, but not likely a functional issue.

Although the modes-of-issuance record is newer than the instance-statuses record, it appears that the modes-of-issuance record has already been referred to in a migration script, so it is probably safer to assign a new UUID to the instance-statuses record.



 Comments   
Comment by Wayne Schneider [ 11/May/20 ]

It does seem that attempting to address this issue could cause a significant migration issue, as all the instance records with either that instance status or that mode of issuance will need to be updated.

Comment by Cate Boerema (Inactive) [ 19/Jun/20 ]

Marc Johnson can you please add a priority to this issue?

Comment by Cate Boerema (Inactive) [ 10/Jul/20 ]

Marc Johnson and Wayne Schneider, how high of a priority is this, especially given the migration issue that would ensue from addressing it?

Comment by Wayne Schneider [ 10/Jul/20 ]

I can't really comment on the priority of this from a functional perspective – as far as we can tell, it makes no functional difference at the moment. It certainly goes against the notion of what a UUID is supposed to be. And it is confusing that the same UUID can represent different records, especially within the same storage module. And, if we choose to address it, the longer we wait, the larger the migration impact (as more customers go live).

The issue of duplicate UUIDs running around the system (which is not limited to inventory storage) does have an effect on attempts to normalize and create relations between types of records which can be useful in data analytics (e.g. LDP) – I believe that was the context in which we first noticed the issue. It makes it more difficult to reason about these relationships in a meaningful way if UUIDs are not really unique, even within a single tenant.

Comment by Marc Johnson [ 14/Jul/20 ]

Wayne Schneider Cate Boerema

I can't really comment on the priority of this from a functional perspective – as far as we can tell, it makes no functional difference at the moment.

Agreed. That likely makes it a P3 or P4 (although we still don't have clear criteria for that).

It certainly goes against the notion of what a UUID is supposed to be. And it is confusing that the same UUID can represent different records, especially within the same storage module.

I agree it is confusing, and is clearly a mistake.

And, if we choose to address it, the longer we wait, the larger the migration impact (as more customers go live).

Indeed, this raises a good point. If we also want to change this for existing installations then we need to consider the impact. At the very least we would need to update the instance records that use this reference record as well. I don't know if anything else relies on it, e.g. data import configuration, other modules in the system.

The issue of duplicate UUIDs running around the system (which is not limited to inventory storage) does have an effect on attempts to normalize and create relations between types of records which can be useful in data analytics (e.g. LDP) – I believe that was the context in which we first noticed the issue. It makes it more difficult to reason about these relationships in a meaningful way if UUIDs are not really unique, even within a single tenant.

I don't really understand this yet. I would expect normalisation to be specific to each kind of reference record.

Comment by Wayne Schneider [ 14/Jul/20 ]

Marc Johnson probably normalization is not what I mean, I apologize for the lack of clarity. The issue we ran across in LDP development is that attempting to infer relationships between records becomes more difficult if UUIDs are not really unique. Nassib Nassar can offer more details, if there is interest. As that functionality of LDP is not yet part of the mainline, it probably doesn't affect the priority. It may be interesting to look at the consumers of FOLIO data outside of the reference UI, but we certainly don't have clear criteria for prioritizing their concerns.

Thanks for taking the time to consider the issue.

Comment by Nassib Nassar [ 14/Jul/20 ]

I may not be the best person to ask. To me this kind of problem is far more important than any functional priority. There might be a migration challenge in fixing it, but the cost of not addressing it could very well continue to increase over time.

Comment by Marc Johnson [ 15/Jul/20 ]

Nassib Nassar

To me this kind of problem is far more important than any functional priority.

I don't think I really understand why it's important.

It might be useful to understand why this is important, in order to decide whether / when to address it. Please could you expand upon why this is more important than new feature development.

There might be a migration challenge in fixing it, but the cost of not addressing it could very well continue to increase over time.

I agree that the cost of correction is likely to increase over time.

Comment by Cate Boerema (Inactive) [ 27/Aug/20 ]

Since there is no functional impact to this, I am changing the issue type to tech debt. I will leave it to you tech folks to hash out the priority of this and let me know if it's something we need to pick up. Thanks

Generated at Thu Feb 08 23:21:49 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.