guys, any chance that
dry-validation 0.10.4 will be released in foreseeable time?
I'm just deciding should I workaround bugs with current versions or just wait a little time
guys, why this example from the doc is not working? http://dry-rb.org/gems/dry-validation/high-level-rules/
schema = Dry::Validation.Schema do
required(:login).filled(:bool?)
required(:email).maybe(:str?)
rule(email_presence: [:login, :email]) do |login, email|
login.true?.then(email.filled?)
end
end
schema.call({login: false}).messages
{
:email => [
[0] "is missing"
]
}
Both on 0.9.5 and 0.10.2
require "dry-validation"
schema = Dry::Validation.Schema do
required(:login).filled(:bool?)
required(:email).maybe(:str?)
rule(email_presence: [:login, :email]) do |login, email|
login.true?.then(email.filled?)
end
end
p schema.call({login: false}).messages
{
:email => [
"is missing"
]
}
works for me
0.10.3 version
~/Programowanie/TestDry bundle | grep dry-v
Using dry-validation 0.10.3
~/Programowanie/TestDry be ruby a.rb
{:email=>["is missing"]}
But the rule is saying that email is not required when login is
false, isn't it?
but error is from second line
required(:email).maybe(:str?)
this check if hash contain key email
this one will be ok
require "dry-validation"
schema = Dry::Validation.Schema do
required(:login).filled(:bool?)
required(:email).maybe(:str?)
rule(email_presence: [:login, :email]) do |login, email|
login.true?.then(email.filled?)
end
end
p schema.call({login: false, email: nil}).messages
{
:email => [
"is missing"
]
}
i returns no error
as I understand, that line checks that :email is a string if it is present
required(:something) just check if key exist
not value
if login will be true it will check if value of email is filled
Oh, I got it
and
schema.call({login: false, email: nil}).messages from your last example probably returns {}
thanks!
yeap
it's strange for beginning because most validation gems do not check keys, only value, and missing key and key will nil value is the same for them
here you have first declare what keys you require to exists and later what value, and on the end logick behind them, like above (conditional check)
it's very powerful tool when you understand how it works
Agree, I already played with Dry-V for some time, and I very like it
I just misunderstood
maybe predicate from that example
optional(:email).maybe(:str?) is suits better to my case, as I'm building API
yeap
Is it possible to control which fields will be present in the
output based on rules?
for me it's not a part of dry-v resposibility to control schema
I guess but it should not be possible
you should have different schema (model) written in dry-t or dry-struct and logic above
but it's how I will do this
maybe someone have any experience with scenario like that and will provide better answer
you design rest api?
for me all field shoudl be always in response
yes, rest api
if you just start I can recommend JSON API. Good to have something other spend a lot of time to dscribe and find best solutions
it start to be a standard for modern api
we decided to use it a week ago :)
good
so yaks, am::serializer, and few others are your answers
they will convert automatically output
well, I'm thinking not about a response, but request processing. From the previous example, what if I want to set email to the model only if login is present
Surely I can define rule to forbid email in the input in that case, but what if I want just to ignore that field
btw, is there a way to make struct doesn't require all keys in constructor hash?
@Kukunin probably not, it's how struct works (and Anima), don't know dry-struct but I suppose it works the same
use dry-t inplace (or virtus if you really need or still prefer)
what do you mean under
use dry-t inplace? how can I replace struct with dry-t?
I think I understand about
dry-t inplace. just PORO + dry-t types
class Customer
def name=(name)
@name = Types::Strict::String[name]
end
end
there was Maybe and optional too
declaration
but not sure how it works now
is it up to date
I know that. my original concern was that requiring all fields to set breaks encapsulation. but it makes perfect sense in case of structs - structs aren't objects, but data structures. so, no encapsulation there
is there a way to overwrite key in
dry-container? I try to test it, but it raises exception saying key is already registered
You can use stubs, check out docs
stubs isn't too convenient because you need to stub default argument as well
like allow(container).to receive(:[]).and_call_original
btw, why do you need mutex in default registry if container is
::Concurrent::Hash.new
@Kukunin apparently this is not documented
::Concurrent::Hash.new doesn't prevent concurrent loading which is not a safe thing
I there is an issue about this though, perhaps it can cause a deadlock
^I think there, I missed the word