Hi, I’m looking for a way to turn off coercion on a per Schema basis. Is this possible? To be specific: due to java.util.UUID.fromString() the UUID schema accepts and pads input that has less chars than a UUID. This is undesirable for us, we’d rather the validation fail.
@donavan Can you give an example of a string that is being padded? When I run something like (java.util.UUID/fromString "df2-482d-ba74-fa6d491d78c6")
I get an exception: IllegalArgumentException Invalid UUID string: df2-482d-ba74-fa6d491d78c6 java.util.UUID.fromString (UUID.java:215)
(java.util.UUID/fromString "9ccd5ac-aab7-11e8-98d0-529269fb1459")
does the trick. First group is short one digit.
(def no-padding-uuid (schema.core/conditional
(fn [uuid-input]
(= uuid-input (str (java.util.UUID/fromString uuid-input))))
java.util.UUID))
If you do that, then yada (I saw your original message on #yada ) should coerce it only if the uuid is what you really want
(schema-tools.coerce/coerce "09ccd5ac-aab7-11e8-98d0-529269fb1459" no-padding-uuid yada.parameters/query-coercions)
==>`#uuid "09ccd5ac-aab7-11e8-98d0-529269fb1459"`
but: (schema-tools.coerce/coerce "9ccd5ac-aab7-11e8-98d0-529269fb1459" no-padding-uuid yada.parameters/query-coercions)
throws an exception
you could also do a string length check, or whatever exact conditions you want to enforce?
^^^ @donavan
Thanks, I’m just in the middle of something else, will try ASAP 🙂
no worries. Realized you probably hadn't seen that since I posted it a half hour later 🙂
I haven't tried it via the actual yada parameter coercion, but since the coercer I used is what they use for parameters, I believe it will work