This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-28
Channels
- # bangalore-clj (1)
- # beginners (67)
- # braveandtrue (179)
- # cider (28)
- # cljdoc (1)
- # clojure (132)
- # clojure-conj (3)
- # clojure-dev (1)
- # clojure-finland (6)
- # clojure-nl (2)
- # clojure-russia (6)
- # clojure-spec (19)
- # clojure-uk (62)
- # clojurescript (90)
- # clojutre (5)
- # component (2)
- # cursive (30)
- # data-science (1)
- # datomic (42)
- # duct (9)
- # emacs (1)
- # figwheel-main (158)
- # fulcro (57)
- # funcool (3)
- # hoplon (1)
- # jobs (17)
- # mount (38)
- # off-topic (15)
- # re-frame (53)
- # remote-jobs (2)
- # schema (11)
- # shadow-cljs (299)
- # spacemacs (25)
- # specter (2)
- # tools-deps (54)
- # vim (11)
- # yada (6)
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