-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review lengths of strings in metadata #342
Comments
This issue is tracked on JIRA as RAD-147. |
Comment by Nadia Dencheva on JIRA: Paul Huwe I would think this was a good thing - it caught an error. Isn't it better in this case to enumerate the values? Or does this bring other problems? |
@nden , If the possible values are really known and likely to change only rarely, I think enum's are reasonable. But in this case I feel like we just picked a string length that was the length of our default and never looked again? But maybe someone actually knows the values and they are all fewer than 6 characters? I'm happy to be aggressive about allowing only 'allowed' things when we know what's allowed, but I don't think we should box ourselves in when we don't know what the possibilities are. |
Implement as outlined here (after it is implemented): |
We hit an issue where roman.meta.program.category had a typo where SURVEY -> SURVYEY. This caused downstream problems because roman.meta.program.category is specified in the database as an nvarchar(6), and SURVYEY has 7 characters. We should review the lengths of all of the strings and tend to make them longer than the absolute minimum to fit the one word we know about so far.
Maybe default to ~20 characters for strings where we don't know what to expect.
The text was updated successfully, but these errors were encountered: