malli

jf 2024-09-12T15:51:43.243169Z

what is the min and max for :int?

adham 2024-09-12T15:52:28.947319Z

The minimum and maximum accepted values

adham 2024-09-12T15:53:39.493439Z

(m/validate (m/schema [:int {:min 1 :max 5}])
              3)
  ;; => true
  (m/validate (m/schema [:int {:min 1 :max 5}])
              6)
  ;; => false

Samuel Ludwig 2024-09-12T15:56:20.437769Z

or are you asking if theres a point where there's integer overflow/underflow?

jf 2024-09-12T15:57:57.578379Z

yes, Samuel, thank you

adham 2024-09-12T15:59:19.770979Z

Oh, sorry then I assumed it was for the options

jf 2024-09-12T16:00:02.758019Z

I'm not sure how validation is done, or if it's backed by a data type. Integer.MAX_VALUE = 2147483647 for java, but:

(malli.core/validate :int 2147483647) -> true
(malli.core/validate :int 2147483648) -> true

adham 2024-09-12T16:00:22.151619Z

I know clojure.lang.BigInt does not pass but java.lang.Long does. I haven't delved into it

jf 2024-09-12T16:00:54.863359Z

it doesnt look like it's simply about looking for digits because

> (malli.core/validate :int 999999999999999999)
true
> (malli.core/validate :int 9999999999999999999)
false

adham 2024-09-12T16:01:43.630329Z

I assume this is because

(type 999999999999999999)
  ;; => java.lang.Long
  (type 9999999999999999999)
  ;; => clojure.lang.BigInt

jf 2024-09-13T01:27:54.268459Z

yes, thank you! so it looks like there is an actual type backing the validation after all:

> (. Long MAX_VALUE)
9223372036854775807
> (malli.core/validate :int 9223372036854775807)
true
> (malli.core/validate :int 9223372036854775808)
false
> (. Long MIN_VALUE)
-9223372036854775808
> (malli.core/validate :int -9223372036854775808)
true
> (malli.core/validate :int -9223372036854775809)
false

opqdonut 2024-09-13T05:48:22.090849Z

clojure prefers long for primitives, so this matches that

opqdonut 2024-09-13T05:49:20.421129Z

:int matches clojure.core/int?

opqdonut 2024-09-13T05:49:45.682269Z

examples of its behaviour here: https://clojuredocs.org/clojure.core/int_q

Eric Dvorsak 2024-09-12T17:18:06.563099Z

I am writing complex SQL queries including with json aggregates in order to optimize some pathom resolvers Problem: pathom resolvers encourages the use of qualified keywords, and when you start having array_agg and json_agg and alias things around in becomes tedious to have a jdbc builder-fn that works as you want I have been fiddling with Malli to solve this issue and came up with a solution that seems okay, happy to hear any feedback / ideas to improve or alternatives. Here's what I do:

(malli/decode
 [:map {:map/rename-keys {:address :user/address}}
  [:id string?]
  [:tags [:set keyword?]]
  [:user/address
   [:vector
    [:map
     {:map/rename-keys {:street :user/street}}
     [:user/street string?]
     [:city string?]
     [:zip int?]
     [:lonlat [:tuple double? double?]]]]]]
 {:id "Lillan",
  :tags ["coffee" "artesan" "garden"],
  :address [{:street "Ahlmanintie 29"
           :city "Tampere"
           :zip 33100
             :lonlat [61.4858322 23.7854658]}
            {:street "Ahlmanintie 291"
           :city "Tampere"
           :zip 33100
           :lonlat [61.4858322 23.7854658]}]}
 (mt/transformer
  {:decoders
   {:map
    {:compile (fn [schema _]
                (when-let [mapping (:map/rename-keys (malli/properties schema))]
                  (fn [value]
                    (clojure.set/rename-keys value mapping))))}}}))
Essentially I am using a custom transformers to rename specific keys in my maps So in practice I am: • writing a schema of what I expect to come out of my resolver • adding properties to define the key-mappings