how do people practically deal with entity maps that have required keys in one situation, but don't in another situation?

I understand you'll probably have to create a separate spec, but that might require duplicating the entire tree of references to other entities, no?

@stijn best to come up with an example

Hi, I'm trying to spec a map (over which I dont' have control) which uses an inconvenient idiom: for a number of members it accepts either a :membername or :memberid key, but at least one must be present. If there's a single member like this, spec/or is convenient. I naively started producing a number of spec/or specs (of the sort: (spec/def :member (spec/or :by-id (spec/keys :req-un [:member/memberid]) :by-name (spec/keys :req-un [:member/membername])))) but if I merge those with spec/merge or spec/and validation becomes impossible

Let's say that I have (spec/merge ::member1 ::member2) The input for validation of member2 seems to be the output of conform for member1, which becomes a tuple [:by-id val] instead of plain val. Beyond doing some sort of pre processing of the map, any idea of how to address this from spec?

can't you use (s/keys :req-un [(or ::membername ::memberid)]) ?

or as in spec/or?

if so, I didn't try, let me try it

as in or within keys

it supports that

it also supports and, kind of a cool feature

from the docstring: (s/keys :req [::x ::y (or ::secret (and ::user ::pwd))] :opt [::z])

@mpenet thanks, never knew about that

@mpenet wow, that’s cool

I think Alex said this too before, but it was still an undocumented feature

It's in the docstring and the guide

ah, that must have changed then or I misremember

From day one i think no?

@mpenet here it fails on 'all keys must be ns qualified'

@mpenet where in the guide is this?

(clojure 1.9.0)

I see the docstring, so that’s definitely supported

I had typos in my example, I am fairly sure it works with both req-un or req (not in front of laptop atm)

ah got it

I left one in opt-*

perfect, thanks @mpenet 🙂

@borkdude example would be: a Person entity in one case has required fields :person/name :person/birth-date :person/address, and Address has required fields :address/street :address/city, but in another case I want a person with required keys :person/social-security-number and :person/address, but the Address has no required fields. How do you model that? I can define a spec for Person type 1 and one for Person type 2, but both will have a required key :person/address, but the spec for :person/address is different in these two entity map specs.

are all these keys in the same map, or is address in its own map?

address in its own map

@alexmiller I have ran code with a spec for assoc instrumented. it went from 3s to 15 minutes (approx.). I narrowed it down to this: https://gist.github.com/borkdude/54baa8504064779094d7dd35f10865d7#file-patch-clj-L64 it’s about 400x slower than running without instrumentation

well, assoc is used a lot

so, don’t do that?

I’m not sure what you’re looking for from me

it seems to be expensive to validate specs in general: https://gist.github.com/borkdude/54baa8504064779094d7dd35f10865d7#file-patch-clj-L62

I think it’s not expensive in general, it’s expensive to have spec for things used by Clojure to do everything else

because the validation is then also checked during validation

to be clear, I spec’ed a function like assoc, not assoc itself

so I made sure that it wouldn’t be used internally

(def my-assoc assoc) and then spec’ed my-assoc

given that you’re doing these a million times each, they seem pretty fast to me? you’re talking about microseconds per?

if you could provide a narrative rather than just a wall of data, that would help

right. I instrumented an Advent of Code puzzle and the time went from 3s to 15 minutes. That seemed a little but much for instrumentation overhead.

but maybe that’s just the way it is

well, it depends what it’s doing and what you spec’ed

if you instrument something in a hot loop…. then that will be slow

http://muhuk.github.io/validation-benchmark/

was an effort to compare different fws

at a micro level and spec did pretty well there

What are the big changes in spec-alpha2? I’m assuming there are breaking changes, given the artifact has changed names.

cool, thanks. yes, the code was a hot loop. I also tested with spec-alpha2 and saw about the same numbers.

is spec itself also compiled with direct linking?

no

it’s not compiled

ah, that explains something

there’s some trickiness in the circularity between clojure and spec.alpha

and compilation makes that trickier than it’s worth

no problem. thanks for the info