okay so I'm doing this pattern a lot and I'm wondering if there's a more concise way to do it, perhaps to register a s/def with another s/def at creation time?

(s/def :platform.confirm/display-attribute keyword?)
(s/def :platform.confirm/temp-attribute string?)
(s/def :platform.confirm/id string?)
(s/def :platform.confirm/value string?)
(s/def :platform.confirm/edit-attribute keyword?)

(s/def ::confirm (s/keys :req [:platform.confirm/display-attribute
                               :platform.confirm/temp-attribute
                               :platform.confirm/id
                               :platform.confirm/value
                               :platform.confirm/edit-attribute]))

and, while I'm at it ... I'm wondering if anyone has any best practices in combining spec with datomic? Since we already go to all the trouble of making the schema for datomic, has anyone looked into using that for spec?

@goomba This popped up as the second result on a Bing search for using clojure.spec to create datomic schema for me: https://github.com/Provisdom/spectomic -- seems to be what you're looking for?

oh man, and great name too

that's interesting ... they went the opposite way I would've expected, i.e., s/def -> schema

I would've expected schema-ish -> s/def

That makes sense to me. We treat spec as the "system of record" and generate stuff from it.

makes sense. I'm usually just paranoid about "losing" my schema.

I like to see them all written out explicitly. But that would be easy enough with eval-and-replace

I recently answered a Quora question about using clojure.spec https://twitter.com/seancorfield/status/1164714132647530496 (don't know if you can read the answer without a Quora account?)

@goomba clojure.spec can express more info than Datomic schema can so it makes more sense to go from spec -> schema.

wheeee yess! That was another question I had!

@kenny solid point. I was just expecting something more like a hybrid spec/schema, uh... spec

have it all in one place

this is totally fine though

also got a lot of good answers out of it and experienced @seancorfield do a "let me Bing that for you" which is fantastic 😆

I've seen people do both directions, and also start from a 3rd "source of truth" and generate the Datomic schema and spec too

mmm chimeratomic

Attaching schema data directly to the specs is something that interested us too @goomba. From what I remember when we wrote that lib, it wasn't immediately obvious what the best path to doing that would be. Ideally it would've been something simple like attaching metadata to the spec's name (e.g. (def ^{:db/isComponent true} my-spec map?)). That wouldn't work for specs because they are typically defined as keywords which do not accept metadata.

There were 2 other options IIRC. 1) Create a new s/def which accepts a new 3rd parameter. 2) add a function similar to s/with-gen which would attach metadata to the spec itself.

nod... in my lazy imagination it would be something like

{:db/ident       :boot.user/string
 :db/valueType   :db.type/string
 :db/cardinality :db.cardinality/one
 :spec/id        ::string
 :spec/spec      string?}

I mean, that's basically a complete schema map.

I'm not even sold on the :spec/spec with a function there because now that's not even a value anymore

yeah I'm excited to check out spectomic!

I do a ton of datascript/spec work so this is great

I haven't looked at this at all but I'm assuming that this sort of thing would be easier to do with Spec2, given Spec2 allows specs to have docstrings.

hello all. is there a reason that pos? and neg? don’t have built-in generators?

yes, they are not specific to one numeric type

use (s/and int? pos?) or whatever numeric type you need

ok, thanks!

or something like pos-int?