inject constraints & hints into generation process

[zeeshanlakhani]

I've done some work on this that's really specific to our data at sfx (and within private repos). Will look into doing something more general.

• Dive into Prismatic coercers approach

Related Issue/Comment

[lvh]

Hey :-) Thanks for your work on schema-gen!

Right now, I have a schema for

{:type {:v :http},
 :url {:p? #<core$uri_QMARK_ schema_contrib.core$uri_QMARK_@7d625686>, :pred-name URI},
 {:k :method} {:vs #{:get :patch :delete :head :post :put}}}

So, the :url key uses the schema-contrib (which you're one of the main authors of, looks like; thanks for that, too!) URL schema. schema-contrib has some generator stuff but nothing that seems to hook into schema-gen and nothing for the URL type.

So, two questions:

1. Is there a way I can make this work? (That appears to be what this ticket is about.) I.e. can I write a URL generator and just tell schema-gen to use it?
2. Is there a useful way I can contribute schema-contrib URL support to schema-gen?

[lvh]

Suggestion: add a schema->gen* rule for s/Predicate, which defers to a new (defmulti pred->gen :p?). I guess that might interact poorly with some things like Int, because that's just defined as (pred integer?)? (What is the difference between schema->gen with and without *?)

[lvh]

After some more careful reading of the code, it appears that an implementation for schema->gen is sufficient, something like (defmethod sg/schema->gen URI [_] ...). So far I just extended it in my codebase. Yay, multimethods.

Would you like these to be contributed to this library?

[zeeshanlakhani]

Hey @lvh. Thank you for using this and schema-contrib! I plan to give your posts more thought later, but I think extending it within your codebase would be the best approach, as, currently, the goal is to get schema-gen to work for the prismatic-schema's core functionality. Though, I think it'd be great to have your example in the README of the contrib side...i.e. something related to using schema-gen w/ schema-contrib, which would be awesome.

In my work at SFX, previously, we did the same thing and also created a set of custom generators that combined contrib and the more generic ones.

P.S. as you may have noticed by now, schema->gen* (star) is just an additional dispatch-type... which the public interface, schema->gen calls into.

[dmcollie]

Are there any hints about how to handle predicates in the schema definitions? At the moment I'm getting an exception thrown but can I add a multi method for schema->gen* for a specific key somehow?

[gfredericks]

predicates are tricky because in test.check a predicate used with such-that has to be highly likely to pass, w.r.t. the generator it's used with. Meanwhile in schema it's totally reasonable and probably common to use a predicate that would be highly likely to fail for a natural distribution over the relevant space.

I'd like this to be better but don't have any general ideas. I feel like it would likely involve using a more specific set of schema tools that are designed with generation in mind. If you describe your current use case I could speculate about how that might fit.

[zeeshanlakhani]

@gfredericks's right. Predicates make things difficult, but it's also something I've wanted to put more thought into.

[dmcollie]

I have a fairly straightforward constraint just now - strings of a maximum length. Ideally the generated values would respect this constraint. Would an approach be to hint the generator using metadata?

Thanks

Dave.

On 1 Jun 2015 17:17 +0100, Zeeshan Lakhaninotifications@github.com, wrote:

@gfredericks(https://github.com/gfredericks)'s right. Predicates make things difficult, but it's also something I've wanted to put more thought into.

—
Reply to this email directly orview it on GitHub(#2 (comment)).

[gfredericks]

yeah some kind of special schema that has info for schema-gen would work. You couldn't use String directly since a class can't have metadata, but I think both schema and schema-gen are extensible enough that this kind of thing can work. I'm just not sure if there is any kind of useful general solution, or if you'd end up fully specifying the generator every time.