Clojurians Log v2

I’d like to run something by this channel; we’re using UUIDs as Yada parameters and noticed that when the UUID params are a few hex digits short they are padded with zeroes and pass validation. I understand this is ultimately due to java.util.UUID.fromString() and matches the behaviour of the #uuid reader macro but we’d rather it fail validation at this point instead of being coerced by string->uuid then validated. Sa basically the question is, is this intended behaviour for Yada? Should we work around it or possibly submit a PR if it’s not. I imagine this has come up before so I expect it’s the former? Thanks!

Is the uuid in a bidi route? My opinion, I think uuids are more trouble than their worth. The uniqueness is useful, the type (as opposed to a string) less so.

We've seen numerous issues with the way uuids are implemented on various platforms. Time consuming and fiddly for arguably little benefit

Yes, it is a bidi route. That’s an interesting point (UUIDs as strings). At this point the rest of our system assumes they’re UUID instances in too many places to make it a practical change for us. Do you see any value in having the ability to customise the coercions map from user code here: https://github.com/juxt/yada/blob/master/src/yada/parameters.clj#L139 ?

Yes, I think that would be useful. But I also think that the whole area of parameters could be extracted to an optional module which could be entirely swapped out. Parameters are off-piste in yada with respect to RFC specifications. I'm not sure whether they belong to yada at all.

When I get round to updating the openapi (swagger) support I'll think about a better separation