Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Fran Worley
@fran-worley
I split my validations up into existence/ type/ format checks vs more complex database reliant checks like existence or permissions. That way if the simple ones fail, I don't bother going any further
However I might have simple checks on all fields in my form which could have dozens of fields so declaring each one as a dependency would be a PITA
Piotr Solnica
@solnic
but that makes entire group of rules depend on other groups of rules, so ie failing basic check for :name will prevent :email which is completely unrelated to :name
Fran Worley
@fran-worley
I want to start by validating that email, name and birthday exist and are the correct data type. If that group passes then I want to validate some other things which could involve hitting the database etc. If it doesn't then I'll just return the errors back to the user for them to try again.
I usually only split database checks, or safe guards against HTML form hacking (i.e. checking the my user has the right to link to that record) so hints on these rules are a bit irrelevant.
Kiril Dokh
@dsounded
@solnic I do appreciate your job
Fran Worley
@fran-worley
@dsounded he's a bit of a :star2: really. I'm not sure how you find the time @solnic between a job, family and sleep!
Aditya Tiwari
@aditya01933
i want to create schema mix of array and normal param. something like this
PurchaseSchema = Dry::Validation.Schema do 
  each do 
    schema do
      required(:line_item_id).filled
      required(:quantity).filled
    end
  end
  required(:account_id).filled
  required(:stripe_customer_id).filled
end
Piotr Solnica
@solnic
that’s not possible, each is for arrays, you can’t have a schema for a hash and an array at the same time
Aditya Tiwari
@aditya01933
so what's the solution for such kind of problem ?
Piotr Solnica
@solnic
just use two schemas
Aditya Tiwari
@aditya01933
Alright Thanks that would work for me
Fran Worley
@fran-worley

@aditya01933 unless your array is actually accessed via a key i.e.

{ 
  line_items: [
    {line_item_id: 10, quantity: 5},
    {line_item_id: 15, quantity: 3}
  ], 
  account_id: 5, 
  stripe_customer_id: '1103'
}

Then you could keep it all in one schema:

PurchaseSchema = Dry::Validation.Schema do 
  required(:line_items).each do 
    schema do
      required(:line_item_id).filled
      required(:quantity).filled
    end
  end
  required(:account_id).filled
  required(:stripe_customer_id).filled
end
Aditya Tiwari
@aditya01933
Perfect!
Fran Worley
@fran-worley
If there is a chance that 'line_items' could be blank or not an array, you might want to validate that first
Aditya Tiwari
@aditya01933
no line item should be filled.
Fran Worley
@fran-worley
Easy peasy then :smile_cat:
Aditya Tiwari
@aditya01933
Yeah thanks Fran :)
PurchaseSchema = Dry::Validation(ApplicationSchema).Schema do 
  required(:line_items).each do 
    schema do
      required(:line_item_id).filled
      required(:quantity).filled
    end
  end
  required(:account_id).filled
  required(:stripe_customer_id).filled
end

If I am passing ApplicationSchema then it is generating error :

NoMethodError: undefined method `Validation' for Dry:Module

Piotr Solnica
@solnic
@aditya01933 Dry::Validation.Schema(ApplicationSchema)
Aditya Tiwari
@aditya01933
yeah fixed it out.. it was my bad :(
Thanks @solnic
:)
Piotr Solnica
@solnic
@fran-worley I’m gonna be a :skull: - :star2: soon ;)
John Backus
@backus
@solnic looks like I'll have time to wrap up dry-types / dry-struct things tomorrow :)
Piotr Solnica
@solnic
@backus oh that would be amazing
it’s possible I’ll wrap up dry-v too…
we’d have an EPIC release then
John Backus
@backus
I don't know if I'll be able to finish it all but I'll have a solid 6-8 hours
and I can prioritize properly to get the necessary functionality ready and then dive into refactoring
to make it most likely we have something releaseable
I just don't want the schemas in dry-t to have so much duplication :'(
Piotr Solnica
@solnic
this is the tricky part
I optimized for performance hence duplication but who knows, maybe it can be cleaner & faster somehow :)
John Backus
@backus
Yeah I'll try to be conscious of that
The other aspect I'm unsure about is whether constraints should ideally be represented in dry logic as much as possible
or if we would rather do all of this key checking, default value filling, and coercion directly like it currently does
Piotr Solnica
@solnic
dry-logic is now few times faster so we could consider that
and there are opportunities for more optimization there
John Backus
@backus
Cool
I also imagine that, for dry-v and dry-t, the more that can be expressed using dry logic the better (barring big perf hits)
Piotr Solnica
@solnic
yeah I mean that was my intention when I extracted dry-logic (it was part of dry-validation originally)
John Backus
@backus
Right
Piotr Solnica
@solnic

ok folks I’m done with logic/validation stuff…I’d appreciate if you could add this:

gem 'dry-validation', github: 'dry-rb/dry-validation', branch: 'master'
gem 'dry-types', github: 'dry-rb/dry-types', branch: 'master'
gem 'dry-struct', github: 'dry-rb/dry-struct', branch: 'master'
gem ‘dry-logic’, github: 'dry-rb/dry-logic', branch: 'master'

to your Gemfile and run your tests…

Nikita Shilnikov
@flash-gordon
@solnic dry-rb/dry-validation#238 <- I'll update this today
Piotr Solnica
@solnic
@flash-gordon cool, you could collaborate with @cored as he’s working on optional dry-struct support which has the identical problem as it needs feature detection too
@fran-worley hey! could you tell me if latest stuff from master works fine with Reform and friends?
Rafael George
@cored
@flash-gordon hey
@solnic according to that issue the dependency then should be remove from the Gemfile? I mean by optional you mean that the user will install the dependency by itself ?