Clojurians Log v2
malli
Is it worth making malli.util/keys work with schemas that are close to maps?
(mut/keys [:map [:a int?]])
;; => (:a)
(mut/keys [:maybe [:map [:a int?]]])
;; => nil (could be (:a))[:or [:map [:a int?]] [:map [:b :string]]], keys of this doesn't make sense. But maybe keys should traverse through :maybe, or :ands with 1 map schema in them. Is that behavior desirable?It's easy enough to walk the schema form and compile keys from all maps, thats what I would reccomend doing now, but it seems like malli.util/keys could do a little more work here
I think it could be generalized to work with unions and return a list of lists. perhaps a keyword option or under a different name.
(mut/keys-groups [:map [:a int?]])
;; => ((:a))
(mut/keys-groups [:maybe [:map [:a int?]]])
;; => (() (:a))(defn known-keys [s] (apply concat (mut/keys-groups s)))I think that might require a transformation to disjunctive normal form (OR of ANDs).
if could be made extensible if we provide an extension to convert a schema to DNF.
[:maybe [:map [:a int?]]] => [:or [:= nil nil] [:map [:a int?]]]
I guess keys-groups is trivial if converted to DNF, so the real work is DNF. I don't think I've specifically tried this, but I have applied De Morgan laws to schemas which would have a similar shape https://github.com/frenchy64/malli/pull/4/files#diff-9f5ce127b24a172f70188161d9c355f41891bfa64fa107800d6fb7389e2b23cb
even mut/keys could be defined in terms of this:
(defn keys [s] (some seq (keys-groups s)))I see how Operations like keys-groups become trivial because you can analyze each disjunct separately
Got a strange exception/interaction with malli dev-mode (experienced with the last two versions of the lib, unconfirmed on others); I think it might have something to do with the experimental.time interface. Flowstorm doesn't seem to give me readouts of whats happening, but it seems like its happening when calling of one of my instrumented functions (specifically when checking the schema of the return value if I had to guess).
When I run the function outside of dev-mode, there are no exceptions, with dev-mode, I get a java.lang.UnsupportedOperationException, on what seems to be a conversion of some value to an Instant.
I'm writing this now before I do any kind of deep-dive(/learn how to do proper git-bisecting), so I only have rudimentary info and a stack-trace (which I will append in-thread).
It does look like a bug in fipp. I updated the fipp issue you linked but basically it's trying to call .toInstant on a java.sql.Date which according to the docs always throws an UnsupportedOperationException: https://devdocs.io/openjdk~21/java.sql/java/sql/date#toInstant()
Ahhh, ok I just now finally realized it does occur in the above example if I use (java.sql.Date.) instead of (java.util.Date.)~
weird though, I am pulling dates from a mysql DB but they always materialize as an #inst for me normally... just not sure what the source of this is still, I definitely don't have any calls to java.sql.Date in my codebase by itself, unless its involved in some kind of transformation-dance for malli. I do use the experimental.time namespace where I assume this is ultimately coming from, but I'm not seeing any explicit reference to java.sql itself in there?
Yeah, it can be confusing b/c an #inst isn't actually a type:
clojure
user=> (clojure.instant/read-instant-date "2025-06-26")
#inst "2025-06-26T00:00:00.000-00:00"
user=> (type (clojure.instant/read-instant-date "2025-06-26"))
java.util.Date
user=> (clojure.instant/read-instant-timestamp "2025-06-26")
#inst "2025-06-26T00:00:00.000000000-00:00"
user=> (type (clojure.instant/read-instant-timestamp "2025-06-26"))
java.sql.TimestampAHHHHHHH oh wow that makes sense let me confirm
Indeed!!!
ok well, i suppose then i'll need to coerce that inst to a different type until that bug is resolved (though, that repo doesn't seem particularly active...)
I'll also make an issue in the malli repo itself, for documentation's sake at least edit: done https://github.com/metosin/malli/issues/1214
very much appreciate the help @batoms, this ghost has been in my brain for so long now
You're very welcome
OK i have been really trying to get a minimally reproducible example for about two weeks now, not exactly with much success, but I suspect the error is related to this https://github.com/brandonbloom/fipp/issues/85
The error does only happen in the function signature where I use an inst? schema (but also seems to happen if I use a time/instant schema as well), but the stacktrace is pretty much identical to the one from the fipp issue
(just to make clear, I am indeed on the newest version of malli still)
Feeling slightly insane because the error doesn't happen when I try to use a simpler example like so
(def MySpec
(m/schema
[:map
[:some-time [:map [:my-time inst?]]]
[:one-thing :string]
[:another :string]]))
(m/=> my-test-fn [:-> MySpec MySpec])
(defn my-test-fn [m]
m)
(my-test-fn {:some-time {:my-time (java.util.Date. (System/currentTimeMillis))}
:one-thing 22
:another "okay"})I will note that I haven't altered the specs being instrumented in quite some time, and only began experiencing this a few days ago, after an (non-trivially-traceable) series of tangential logic changes.
In addition: of the two schemas in the instrumented fn (both the only argument, and the return value), they both validate without error when done separately.