schema

2017-10-16T12:00:25.000442Z

I did something similar at some point (adding “Any”) in one of our apps for coercion, as I wanted to coerce as much as possible, and leave the extra keys if they were there (since it coerces data from DB, which may change etc.). Then I changed the approach to basically reduce over the schema and apply the coercion only in the parts that were defined in the schema and coercer. This made it much closer to “hand-made coercion” (ie. equivalent to (-> data (update-in :my-key parse-my-key) (update-in :foo parse-foo)) but reusable with schemas).

2017-10-16T12:01:00.000168Z

(I did not check the performance though - reusing the coercer would sure be nice)

ikitommi 2017-10-16T12:47:01.000158Z

@nha does the reduce version work with nested/wrapped schemas (vectors, maps, maybes)? With the open-schema approach, the client coercer would look ~this:

(defn coercer [schema matcher {:keys [open?]}]
  (let [f (if open? schema-tools/open-schema identity)]
    (schema.coerce/coercer (f schema) matcher)))

(def schema {:a Long, :b [(s/maybe {:a Long, s/Keyword s/Keyword})]})

(def schema-coercer (coercer schema (constantly nil) {:open? true})

(schema-coercer {:a 1, :b [{:a 1, "kikka" "kukka"}], "kukka" "kakka"})
; {:a 1, :b [{:a 1, "kikka" "kukka"}], "kukka" "kakka"}

ikitommi 2017-10-16T12:48:22.000386Z

and yes, it would be nice to have this in a matcher but I guess it would need a lot of rework in the Schema side..

2017-10-16T14:09:21.000604Z

Ah right I did not need to handle nested schemas since in my case the data is coerced when coming from database and is “flat”. I will check open-schema when I work in this area again - this looks nicer than what I have right now 🙂 thanks for the snippet!

ikitommi 2017-10-16T17:29:45.000426Z

np, released the 0.9.1 schema-tools with that.

1