[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 ] |
Agreed. That likely makes it a P3 or P4 (although we still don't have clear criteria for that).
I agree it is confusing, and is clearly a mistake.
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.
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 ] |
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.
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 |