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