@bbloom > what’s the guidance for spec-ing pseudo-namespaced keywords? i’m thinking like datomic attributes when you do :customer/name or something like that I’ve actually been using it like this pretty much exclusively and I feel reading and referring to the spec becomes pretty trivial especially when you have multiple types that have the same name but the namespace disambiguates it (like multiple name fields for instance :customer/name :business/name)

Hey guys! Using clojure-spec for the first time to describe a db schema. Does this look okay or am I doing something obvious wrong?

(s/def ::first-name string?)
(s/def ::last-name string?)
(s/def ::username string?)
(s/def ::picture (s/nilable string?))
(s/def ::relationship-type int?)

(s/def ::friend (s/keys :req-un [::username ::last-name ::first-name ::picture ::id ::relationship-type]))
(s/def ::friends (s/coll-of ::friend :kind vector?))

(no error, just want to check in)

I think I don't completely understand why :req-un is necessary

@dvcrn :req-un so when you pass in the data to be validated you can do

{:username "",
   :last-name "",
   :first-name "",
   :picture "",
   :relationship-type -1}

also try out (s/exercise ::friend) to test out your specs 😉

@naomarik I can't follow. You mean with req-un I can leave out keys?

without :req-un you do something like this:

{:friend/username "",
 :friend/last-name "",
 :friend/first-name "",
 :friend/picture "",
 :friend/relationship-type -1}

ah, I see!

so these are fully qualified keywords

which is very useful imo when dealing with multiple entities in the same map

helps disambiguate whose ID or name you’re talking about

right 🙂

so I guess fully qualified / namespaced keywords are better

i’m not qualified to give an answer on that but i can say at least in my extremely limited usage on an immature project it has helped me discern what data i’m looking at

yeah completely makes sense

unqualified keywords would usually come from/go on wires