[FOLIO-2034] decision: UUID Validation Created: 21/May/19  Updated: 08/Feb/21  Resolved: 03/Feb/21

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: Marc Johnson Assignee: Unassigned
Resolution: Done Votes: 0
Labels: platform-backlog, potential-decision, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to MODINV-199 Move schema for uuid from inventory Open
relates to CIRC-321 JSON schema problems with request.json Closed
relates to FOLIO-972 The regex pattern for UUID in schemas... Closed
Sprint: CP: R3 2022 roadmap
Development Team: Core: Platform

 Description   

There are at least two regular expressions used for UUID validation in FOLIO.

In order to be consistent across the APIs it could be valuable to decide on a standard.

The two regular expressions are as follows

Version Restricted

"^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-5][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$"

Unrestricted

"^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$"


 Comments   
Comment by Marc Johnson [ 21/May/19 ]

Jakub Skoczen Adam Dickmeiss Julian Ladisch Matt Reno Craig McNally Kostyantyn Khodarev Taras Spashchenko Ian Ibbotson (Use this one) steve.osguthorpe Ryan Laddusaw Jeremy Huff Niels Erik Nielsen

Thoughts?

Please feel free to add others folks

Comment by Craig McNally [ 21/May/19 ]

I personally prefer the more specific pattern which limits to the existing UUID versions 1-5 and variants 1,2. I'm guessing that in the vast majority of cases v4 variant 2 is being used.

Do we have any idea of which pattern is more prevalent in FOLIO? I all of the modules I've worked on use the more specific pattern.

Comment by steve.osguthorpe [ 22/May/19 ]

Yeah I'd be in favour of the more strict pattern.

Comment by Julian Ladisch [ 22/May/19 ]

I prefer the restricted version. Quote from https://dev.folio.org/guides/uuids/ :

How to check for a valid UUID

The regexp ^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[1-5][a-fA-F0-9]{3}-[89abAB][a-fA-F0-9]{3}-[a-fA-F0-9]{12}$ matches any valid UUID. This accepts v1, v2, v3, v4 and v5 UUIDs as FOLIO allows all of them, but it excludes the Nil UUID 00000000-0000-0000-0000-000000000000 that usually serves as a NullObject to be used for the Null Object Pattern.

A UUID has the form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx where the version M must be [1-5] and the variant N must be [89abAB]

See UUID at Wikipedia.

https://en.wikipedia.org/wiki/Universally_unique_identifier

Comment by Niels Erik Nielsen [ 26/Jul/19 ]

Applying this pattern, the API will accept UUID fields with a null value (if the field is non-mandatory of course), but it will reject the input if the UUID is set to the empty string.

Should it accept the empty string too?

I'm asking because as of the latest release of mod-inventory-storage (16.0.0), we've begun implementing the pattern, starting with the instance object, and it caused an issue in ui-inventory, where the UUID field instance.contributors.contributorTypeId was defaulted to the empty string, see UIIN-655 Closed

For comparison, the field instance.electronicAccess.relationshipId is defaulted to null.

The API will accept if the user don't fill relationshipId but it would reject if the user didn't fill contributorTypeId, even though both are optional. For now we (Zak Burke) have changed ui-inventory to default contributorTypeId to null as well.

Comment by Marc Johnson [ 26/Jul/19 ]

Niels Erik Nielsen

Should it accept the empty string too?

I don’t think an ID property should accept an empty string. To me, that would undermine the other validation.

If we did allow an empty string, how should the system interpret it?

For comparison, the field instance.electronicAccess.relationshipId is defaulted to null.

Is that null within the UI or as what is included in the representation sent to the server?

The API will accept if the user don't fill relationshipId but it would reject if the user didn't fill contributorTypeId, even though both are optional.

This might be part of a broader topic, of how to represent fields that have no value in JSON.

Personally, I think that fields that aren’t given a value, should be represented as the omission of the JSON property (rather than null, empty strings or any magic value).

For this scenario, that would mean that if no contributor type is chosen in the UI, there should be no contributorTypeId property in the JSON.

Does that make sense?

Comment by Niels Erik Nielsen [ 26/Jul/19 ]

Thank you, Marc Johnson. Then Zak Burke's fix to ui-inventory stands for now.

As for omitting the field I think you're right that it's a broader topic, The field is now "omitted" by ui-inventory code but still set to null if not set by the user; I assume by the repeatable field component or its underlying libraries (redux-form?).

Comment by Ann-Marie Breaux (Inactive) [ 24/Jan/20 ]

Hi Ian Walls adding you as a watcher on this issue, since you were talking about whether we ensure support for multiple standards or UUIDs or one standard for UUIDs.

Comment by Marc Johnson [ 28/Jan/20 ]

Given that the official documentation states that the FOLIO uses the version restricted version. Is this issue needed anymore?

I thought it had been decided elsewhere that was the way FOLIO had chosen to go (without a decision log, that is difficult to verify).

Comment by Julian Ladisch [ 28/Jan/20 ]

Jakub Skoczen: Do we need a discussion whether we want to change the UUID validation from the restricted version to the unrestricted version?

Comment by Julian Ladisch [ 07/Feb/20 ]

Jakub Skoczen: Do we need a discussion whether we want to change the UUID validation from the restricted version to the unrestricted version?

Comment by Jakub Skoczen [ 07/Feb/20 ]

Julian Ladisch can you bring this issues up on our Monday planning session?

Comment by Jakub Skoczen [ 10/Feb/20 ]

Julian Ladisch Adam Dickmeiss Marc Johnson We discussed that the restricted regex is the way to go. We need a list of module where schema and/or sample/reference data needs to be changed to use the restricted version – Julian Ladisch can you please put a list of modules here? Suggestion is to put this in the RMB upgrade notes.

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