-
-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conditionally Required Fields #582
Comments
I'm not entirely sure how to solve this yet, but what I am sure is that this is definitely not something that will require extending the schema DSL. Maybe we could have a mechanism for converting existing schema from required keys to optional. Anyway, this is something that dry-validation can solve eventually, so I'm moving this issue there. |
@dwilkie you could just send all of those params again, instead of sending blank values on update. |
@solnic Do you have any ideas on how dry-validation can solve this ? Something like having variants of a schema ? Or having another api to transform the main schema ? We are needing this feature as well in order to not duplicate contracts that have different schemas. |
@bilby91 I don't have. For the time being you can simply do this: require 'dry-validation'
class UserContract < Dry::Validation::Contract
def self.define_params(key = :required)
params do
public_send(key, :name).value(:string)
public_send(key, :email).value(:string)
end
end
end
class UserContract::Create < UserContract
define_params
end
class UserContract::Update < UserContract
define_params(:optional)
end
create_contract = UserContract::Create.new
create_contract.(name: 'Jane', email: 'jane@doe.org')
#<Dry::Validation::Result{:name=>"Jane", :email=>"jane@doe.org"} errors={}>
update_contract = UserContract::Update.new
update_contract.(email: 'jane@doe.org')
#<Dry::Validation::Result{:email=>"jane@doe.org"} errors={}> |
I had a related query to this issue which I was about to ask and thought let me first check if I can find any related issues in open issues list and I ended up finding this. My use-case is I have following schema for an Address model I have:
I have a need wherein applying a rule on optional
Is something like that possible? My setup
Thanks. |
@jiggneshhgohel no it's not possible. Once you're within a rule your schema is already established so you can't alter it based on input. |
@solnic Thanks for the prompt response. |
I am having the same issue. What I am trying to do is:
Looks like it's not possible using dry-validation. The equivalent JSON schema looks like: {
"anyOf":
[
{
"title": "foo is true",
"properties": { "foo": { "type": "boolean", "enum": [true] } },
},
{
"title": "foo is false",
"properties":
{
"foo": { "type": "boolean", "enum": [false] },
"bar": { "type": "string"},
},
"required": ["bar"],
},
],
} |
Dependencies between fields must be handled via rules, not through the schema dsl. |
In many REST APIs it's often the case when creating resources, certain fields are required but when updating resources, all fields are optional and only the fields which are provided are updated.
Examples
For example, the following schema is good for validating user creation.
But when updating a user, we need the following schema:
We don't want to repeat the schema and the rules
My first thought of a possible solution would be something like:
For a PATCH request, the resource could be injected as an external dependency, for a POST request the resource doesn't exist yet so it's not injected.
The text was updated successfully, but these errors were encountered: