[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: |
|
||||||||||||||||
| 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. |
| 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
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 ] |
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?
Is that null within the UI or as what is included in the representation sent to the server?
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. |