You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, readLength is a string. This seems like it should be a number, though. When using JSON validation, numbers input to a string variable are considered invalid.
Would changing readLength to a string break anything for anyone?
The text was updated successfully, but these errors were encountered:
@Aryllen We have a lot of contributors provide readLength values that are non-numeric, e.g. "100bp" or "28/56/100" for hashtagged libraries. I haven't been enforcing numeric values because the key is a string, and there are some legacy studies with non-numeric readLength annotations. 😬
I agree it should be numeric, so if we want to change it I could try to edit all the non-numeric values...
Okay, that's a tough call. Editing all of those would take time and the hashed or range ones would be an issue still. I'm going to leave this open, but let's leave readLength as a string for now. It could be changed later. Just be aware that the annotation editor in the web will complain if someone tries to annotate with a number.
Currently, readLength is a string. This seems like it should be a number, though. When using JSON validation, numbers input to a string variable are considered invalid.
Would changing readLength to a string break anything for anyone?
The text was updated successfully, but these errors were encountered: