My intuition says it belongs to the map. But I guess, it depends. Being part of the entry-tuple, you could for example merge two maps with mapping to same domain and the mappings would be merged automatically

e.g.

[:merge
 [:map [:a {:rename/SAP "SAP_A", :rename/SALESFORCE "sf_a"} int?]]
 [:map [:b {:rename/SAP "SAP_B"} int?]]]

not actually sure if the entry properties get merged correctly here, just guessing 🙂

Followup harder question - if I rename in decode it reports error on the wrong key path!

I dug myself a deeper hole than expected 😄

How do I get out?

The only way I see around it is attaching as metadata the rename mappings and encode the error report on response

could you gist a minimal case, I can try to figure out howto

Sure, I'll send it over later today / tomorrow morning

(defn key-renamer
  "Take a tuple of keys [`k1` `k2`] and return a function of a map `m`
  which will replace `k1` with `k2` if it exists in `m`"
  [[k1 k2]]
  (fn -rename [m]
    (if-let [[_ v] (find m k1)]
      (dissoc (assoc m k2 v) k1)
      m)))

(defn- -compile-rename-keys-transformer
  "Takes a map of keys->keys and returns a function which will rename the
  keys in LHS to RHS if they exist in a map."
  [m]
  (if (seq m)
    (reduce comp (map key-renamer m))
    identity))

(def rename-keys-transformer
  (mt/transformer
   {:decoders
    {:map
     {:compile
      (fn [schema _]
        (-> schema m/properties :rename -compile-rename-keys-transformer))}}}))

(comment
  (m/decode
   [:map
    {:rename {:a :b :c :d :x :y}}
    [:b int?]
    [:c int?]
    [:y int?]]
   {:a 1
    :c 2
    :x 3}
   (mt/transformer rename-keys-transformer)))

@U055NJ5CC

had time to look at this. Thing is, you should describe the resulting schema, not the orginal.

so, it should be:

[:map 
 {:rename {:a :b, :c :d, :x :y}}
 [:b int?]
 [:d int?]
 [:y int?]]

The problem is that schemas, being a description of "ought", can't report back errors about "is" for any lossy transformation

I had a typo in the last entry which I can spot now

Anyway, schema validates b, user gave me a, I want to report back "a should be an integer" if I was given a, even thought I treat it as b. Some sort of alias mechanism

ok, that :thinking_face:

what if the rename-map is used to create the target (or source) schema?

e.g. transform keys.

then, you could validate them separately.

(def Target
  (m/schema
   [:map
    [:b int?]
    [:d int?]
    [:y int?]]))

(def mappings {:b :a, :d :c, :y :x})

(def Source
  (mu/transform-entries 
   Target 
   (partial map (fn [[k p v]] [(mappings k k) p v]))))

Source
; => [:map [:a int?] [:c int?] [:x int?]]

something like that, explicit schemas for both Source and Target.

I would like to see someone cook Meander and Malli together, so that one could write a Malli schema and a Meander transformation for it and infer the target Malli schema from those.

might be the ultimate data transformation tool 😎

I started off with a separate schema, I wanted to be clever and unify

Regarding meander, I also thought on using it for the complex unification problems I made for myself

Add a "match" property to schema which binds, then compile that to meander pattern and match on it

Or going the other way, write a meander to malli compiler

Then schemas reflect how data looks

And you can go crazy with unification

See https://github.com/metosin/malli/issues/555

Thanks. We’ll probably implement some fn schema to check for satisfies or instance for now I guess!

doh’ i mean the obvious here is wrong…one sec..

(being the map in one call and string in another) lol…

I compounded a couple of issues but I dont think its Malli…. I think it might be coercion from reitit. Sorry bout that, another pair of eyes found the painfully obvious string where a map should have been in my example 😐

yeah no issue… happy monday