What kind of edge cases would not be covered using a naive impl? Benchmarks most welcome!

All the use cases would be covered by using a naive impl. Some edge cases might have a high computational cost in a naive impl while a smarter impl would mitigate the cost of their parsing. The edge cases I am thinking about are consecutive sequences of variable length. But I am not sure if it is a real concern or my imagination.

;; JVM started with -Dmalli.core.registry=malli.mutable/registry

(require '[malli.core :as m])
(require '[malli.mutable :as mm])

(mm/register! ::age [:and int? [:> 18]])

(m/validate ::age 20)
; => true

🙈

I also don’t like the idea to lose the property of working with immutable values.

I would suggest users who don’t want to have to pass the registry as option to Malli all the time to just create their own wrapper functions.

;; in my-ns
(defn validate [schema data options]
  (m/validate schema data (assoc options :registry my-registry)))

I was facing the same situation in projects which use Vrac, and I used the wrapper pattern everywhere. It’s really not a big deal and it keep the satisfaction of working in an environment where we don’t even have to think about the side effects.

we are talking about validating data structures, not string content.

:thinking_face:

@U8SFC8HLP see https://clojure.org/guides/spec#_sequences

Right, thank you. I got confused, quite obviously 🙂

Just curious, what kind of metadata you mean? PostgreSQL’s information schema is already quite extensive…

I have some code that does the same. I wasn't able to find a good solution for restricting string length. Maybe that has changed in the meantime.

In PostgreSQL `TEXT` is string with infinite length (_=<https://wiki.postgresql.org/wiki/FAQ#What_is_the_maximum_size_for_a_row.2C_a_table.2C_and_a_database.3F|1GB> because that is any field’s maximum size_); string with specific maximum should be done with `VARCHAR` columns in which case `information_schema.columns` `character_maximum_length` has the column’s size limit information.

Assuming I’ve understood correctly, I seem to have a lousy track record on that part this week… 🙂

The JDBC API also offers metadata, but probable less than direct PostgreSQL use. Prior art in spec land: • https://github.com/tatut/specql • https://github.com/viesti/table-spec

@U2APCNHCN the specql implementation might be really good help in looking what postgresql offers

JDBC https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/DatabaseMetaData.html is very extensive, haven’t tested but it seems with https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/DatabaseMetaData.html#getColumns(java.lang.String,java.lang.String,java.lang.String,java.lang.String) COLUMN_SIZE has the maximum length; the same TEXT/VARCHAR size detail as described above of course still applies.

yup, although I have a feeling that it might lack info on postgresql specific extensions

Yes, DatabaseMetaData is what I currently use. My showstopper right now is that I can't get the data transformations to work...

I haven't heard of specql so far, but I will give it a look

Might be just me but if I were doing something very product specific, I’d steer far away from any kind of abstraction and just go as raw and bare in as possible… 🙂

Well I think the problem wih going as raw and bare as possible is that you lose all the flexibility. And we're going to need that flexibility. My competition for creating forms are airtable and typeform. And I'd prefer we don't use either of those for our product