Fork me on GitHub

@don.dwoske Where do you get this data from? Can you use :person/properties and :house/properties instead or do you treat ::properties as just a bag of key-value pairs? Or maybe use :properties without namespace so you can have the same keyword with different specs such as (s/def :person/properties ...) and then (s/keys :req-un [:person/properties] ...).


Or perhaps be strict about a flat structure such as {::id 2, ::type "house" :house/color "red" :house/style "Victorian"}


I’ve got a flat structure working decently now. Your idea to use different namespaces for each properties list is a good one, that should work I think. The spec is used to validate data with unqualified keys, so it fits. I only need the properties map name to be consistent across all types. We have not yet finalized our design for these payloads, but if I can get the specs working both in flat and nested properties format, that would be excellent.


BTW, for those interested, I’m building out a proof-of-concept to compare using clojure.spec on an enterprise level to define and validate our entity types vs. something homegrown vs. XSD, vs. JSON Schema vs. Avro vs. whatever else. Barring any setbacks, I may propose using clojure.spec as the place-of-truth for these, and using tools to translate to any other format we may need.


I’d be curious also to know if there is a way to use clojure.spec to define a web API contract and then auto-generate swagger docs from it.


The json schema stuff in spex is far from finished. Wouldnt rely on it


We might just use graphql instead actually


@U050SC7SV we are looking at graphql as well - any particular database or libraries in mind?


We use a mix of ES and cassandra, but graphql usage doesnt really depend on a particular datastore. I am experimenting with the lib from Walmartlabs, so far impressed


I thought you could lookup :ret/`:args` on a spec, e.g. (:ret (s/get-spec 'full/symbol)) but this is just returning nil :thinking_face:


the type of the spec is clojure.spec$or_spec_impl$reify__13856


right so i wasn't trying it on an fdef spec. i was trying it on an s/keys spec. however, still can't seem to get much useful info out of it. (e.g. which keys are specified as :req vs :opt)


You have to call s/form and parse the form