These are chat archives for dry-rb/chat

15th
Sep 2016
Daniel Gollahon
@dgollahon
Sep 15 2016 00:01
Is there a way to append to a schema? Or have another schema mixed in? (for instance, I might have something that validates a and b in one schema and something that validates a, b, and c in another and right now I duplicate the logic for a and b. In this case the common attributes are top level, not reused objects like you can nest schemas for (as suggested here http://dry-rb.org/gems/dry-validation/reusing-schemas/).
*copy and then append to, actually
Piotr Solnica
@solnic
Sep 15 2016 01:21
@dgollahon it is possible but I haven't come up with a nice API for that so it is kinda rough atm. I will show you how a bit later today, not in front of my laptop now
Daniel Gollahon
@dgollahon
Sep 15 2016 02:59
@solnic: great, thanks. :)
Piotr Solnica
@solnic
Sep 15 2016 03:28
@dgollahon wait, you want to inherit them how exactly?
@dgollahon ie if you have rules for a in two schemas, you’d like to AND them?
Daniel Gollahon
@dgollahon
Sep 15 2016 03:30

Well, mainly looking to understand all the reuse options available because i only know what's in that docs page^

In this case i basically want the equivalence of inheritance and I was unsure if you could do something like that. a, b, and c just represent different keys I want to validate. If object A has the a and b attributes and object B has A's attributes plus a new one, c, I'd like to be able to reuse my a and b validations.

or something like a mixin if i have year, month, day attributes in multiple places i might like to mixin the date schema i've built.
for a date with year, month, and day though it's likely they'd be in a separate object and i could use the reuse mechanism from the docs
but i have a few equivalent cases where i have more than one object with common "flat" attributes
does that make sense?
Piotr Solnica
@solnic
Sep 15 2016 03:33
@dgollahon I see, I thought you had two schemas with rules for the same key and wanted somehow to combine those
Daniel Gollahon
@dgollahon
Sep 15 2016 03:34
ah, no. but that could also be helpful in some cases.
my app has a reasonable number of schemas now, but they're starting to grow and they have a good bit of duplication so i'm trying to narrow down a few cases.
Piotr Solnica
@solnic
Sep 15 2016 03:35
this is easily doable but I won’t add it unless somebody actually has a use case and reports an issue :)
sure, gimme a sec
Daniel Gollahon
@dgollahon
Sep 15 2016 03:36
ok, sometime i'll review the schemas we have and think about what i'd ideally want and when i've got a clearer open an issue or discuss here. like i said, it's not out of hand yet... but i could see the duplication getting that way.
just was curious if there were already more mechanism that i didn't know about beyond just doing .schema(other_schema)
Piotr Solnica
@solnic
Sep 15 2016 03:39
require 'dry-validation'

OneSchema = Dry::Validation.Schema do
  required(:name).filled(:str?)
  required(:email).filled(:str?)
end

AnotherSchema = Dry::Validation.Schema(OneSchema) do
  required(:age).value(:int?)
end
@dgollahon ^^
this will prepend rules from OneSchema
Daniel Gollahon
@dgollahon
Sep 15 2016 03:40
oh, interesting
that's actually exactly what i was asking about
Piotr Solnica
@solnic
Sep 15 2016 03:40
if you have more you can do this too:
Dry::Validation.Schema(Dry::Validation::Schema, rules: SomeSchema.class.rules + OtherSchema.class.rules)
so as you can see, it’s awful :laughing:
Daniel Gollahon
@dgollahon
Sep 15 2016 03:41
haha
Piotr Solnica
@solnic
Sep 15 2016 03:41
there’s an issue about it
Daniel Gollahon
@dgollahon
Sep 15 2016 03:41
that last one is a little awkward, yeah
Piotr Solnica
@solnic
Sep 15 2016 03:41
well, it’s just not done yet (hence no docs too)
Daniel Gollahon
@dgollahon
Sep 15 2016 03:41
but the first case seems potentially useful. i'll have to tinker with it.
yeah
totally understand
Piotr Solnica
@solnic
Sep 15 2016 03:42
this is tricky stuff so it’s taking some time
Daniel Gollahon
@dgollahon
Sep 15 2016 03:42
yeah, definitely
Piotr Solnica
@solnic
Sep 15 2016 03:42
schemas have all sorts of properties, so it’s not just “use inheritance Luke!”
Daniel Gollahon
@dgollahon
Sep 15 2016 03:42
but good to know there's an effort about it.
haha, yeah.
Piotr Solnica
@solnic
Sep 15 2016 03:42
well, we just need to come up with an API :)
because internals are ready
Daniel Gollahon
@dgollahon
Sep 15 2016 03:42
and "use inheritance Luke!" is also not inherently simple.
cool
Piotr Solnica
@solnic
Sep 15 2016 03:43
that too :)
schema rules is just an array with rules, so we can append stuff, prepend stuff, compose with others, whatever we want
and since input processors are decoupled, this doesn’t affect the rules at all
furthermore, message compilation is decoupled too, so we can easily tune message settings for a schema that inherits rules from multiple other schemas that have different message settings :)
Daniel Gollahon
@dgollahon
Sep 15 2016 03:46
neat, seems great. just time to do some API pondering.
seems like some of the harder parts will be if you have collisions
where both schema A and B operate on key foo.
Piotr Solnica
@solnic
Sep 15 2016 03:49
we can do stuff like [a_rules.select { |r| r.name == :foo } + b_rules.select { |r| r.name == :foo }].reduce(:and)
errrr s/select/detect/
this stuff is crazy flexible so we can either do this, or make it configurable, or raise an error, dunno :)
Daniel Gollahon
@dgollahon
Sep 15 2016 03:51
yeah. i would expect you could inadvertently get contradictory rules with an and. but maybe that's just your fault and ohwell :P
might be less surprising to raise an error. but i don't know, there may be a reasonable alternative.
Juanma Cervera
@jmcervera
Sep 15 2016 17:13
Hi, A question about testing.
I'm developing a dry-system project, where my functional classes are registered in the app container.
I instantiate the objects in specs through the container as I do in the app.
How should I instantiate the subject object when I want to mock some of the dependencies,
with mocks or lambda functions to avoid for example go to the database through a repository?
Should I instantiate the object with new and not use the DI?
Is there a way to mock only some of the dependencies and get DI work for the others?
just use .new + kwargs (it’s the default constructor type in autoinject)
Juanma Cervera
@jmcervera
Sep 15 2016 20:23
@solnic Thanks :smile: