Fork me on GitHub

hi all. there is bunch of quality PRs being held in the queue, sorry. I’m working on with the malli internals (schema ast, lifecycle, providers, registries) and want to find a good design before merging anything big in. Will review and pull the queued PRs after that. Any small fixes welcome anytime.

Ben Sless09:10:57

Necroing a question I asked some time ago, any idea for a transformer which removes invalid keys?

Ben Sless09:10:08

(given that they're optional)


invalid… you could a) validate the keys when transforming or b) explain and remove based on that.

Ben Sless09:10:45

I think I can build (a), the transformer has access to the parent schema

Ben Sless09:10:21

Also reminds me, I think an interleaved transformer/validator will be good


doing both in a single pipeline?

Ben Sless09:10:29

The decoder can end up doing lots of allocations

Ben Sless09:10:42

you can short circuit on it


but, you can’t validate before it’s transformed, right?


so, it would need to happen on :leave -> it’s all transformed already?

Ben Sless09:10:27

you'll have something like a coercer which transforms and validates in one pass


how would it allocate less if that happens after the transformation?


wouldn’t all the nested childs get re-validated when you are leaving them?


[:map [:a [:map [:b [:map [:c [:map [:d :boolean]]]]]


unless the walking knows which childs are already transformed & validated.

Ben Sless09:10:21

hm, generally, you have no way of knowing if you need to re-walk the children

Ben Sless09:10:33

especially if you do interesting transformations


my assumption is that having validation and transformation as separate steps is the fastest way to do it. 2 simple sweeps instead of one (more complex) sweep.


but, all ears if there is a better way.


originally, i though of doing all the workers using just -walk. there would be walker to create a validator, decoder etc. but as all schemas should have all of those and as performance was a one of the primary goals - they got separate (protocol) methods.


the one walker would have allowed to compose a chain of validate + transform in an easier way, I think.

Ben Sless10:10:20

Figured out how to strip invalid optional keys, feel free to add it to tips, after some beautifying

(defn strip-invalid-optional-keys-transformer
   (let [transform
          (fn [schema _]
            (let [entries (filter #(:optional (m/properties (second %))) (m/entries schema))
                  fs (map (fn [[k v]]
                            (let [validator (m/validator v)]
                              (fn [m]
                                (if-let [e' (find m k)]
                                  (let [v' (val e')]
                                    (if (validator v')
                                      (dissoc m k)))
              (reduce comp fs)))}]
      {:decoders {:map transform}
       :encoders {:map transform}}))))

Ben Sless10:10:42

(m/decode [:map [:a {:optional true} int?] [:b {:optional true} int?]] {:a 1 :b 2.2} strip-invalid-optional-keys-transformer)


a) might be cleaner (and faster)?


:or does also validation on transformation, as it needs to find the branch, which is valid after transformation.


spike about caching computations (`-form`, -validator etc) with schemas:

(def schema
    [:x boolean?]
    [:y {:optional true} int?]
    [:z [:map
         [:x boolean?]
         [:y {:optional true} int?]]]]))

;; 1.5µs -> 11ns (130x)
 (m/validator schema)

;; 1.7µs -> 64ns (25x)
 (m/validate schema {:x true, :z {:x true}})) ; => true


there is the initial cost of creating the thing, but just once opposed to every call. the results are cached with the actual schema instance, so when the schema instance is not needed, the cached results will also be GCd, so not leaking memory.


using computation directly is still fastest, but not much:

;; 55ns
(let [validate (m/validator schema)]
   (validate {:x true, :z {:x true}})))

Ben Sless12:10:40

Please disregard last message, user error