Fork me on GitHub
Vincent Cantin02:03:45

@ikitommi will need some adjustments if we want to use it in Malli: • Its implementation is not cross platform. • The maps returned by se/exec contain the keyed groups in the middle of :rest and :match , that could be a problem when the keys of those groups are controlled by Malli’s users.


@vincent.cantin ok. The cross-platform should be doable, ig Cristophe takes PRS (there should be an issue about that), not sure about the second. If that is not a good base lib to use, do you have plans on using something else? or from scratch?

Vincent Cantin06:03:05

I started to scratch my head about a new impl this morning. What's next depends on what features we want to offer the users.


just commented on the issue

Vincent Cantin06:03:28

I think that an optimized & naive impl might be faster on most use cases compared to a general algorith that works in theory faster and cover all edge cases. I would like to put them to a benchmark on realworld usages.


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

Vincent Cantin02:03:39

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.


did a quick draft of a swappable default registry: idea that the default registry could be bootstrapped into something that satisifes m/Registry protocol. There could be malli.mutable with an alternative impl using a extra atom to look for the schemas and malli.mutable/register!to register schemas into that. This would be a simple -> easy helper, already not happy with that. Comments welcome


;; 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

Vincent Cantin02:03:35

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

Vincent Cantin02:03:18

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)))

Vincent Cantin02:03:43

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.


Is cross-platform regex even possible? Beyond basics I don’t think JS/Java/C# regex engines are even close to compatible with each other.

Vincent Cantin09:03:46

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




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


are recursive schemas possible w/ malli?


e.g. defining a schema for a {:name "something" :kids [{:name "something" :kids [....]}]}


sorry just reading the whole of that linked issue and I see you guys are putting a lot of thought and effort into your approach so I will wait and see!


I am about to start to try generating Malli schemas from PostgreSQL metadata. Very curious how far I can take this. If I find a way to store additional custom metadata in the database, I could end up generating 90% of a form simply by converting Postgres metadata, the rest being the layout.

👍 8

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 (_=<|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: •


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


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