Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 12 21:34
    flash-gordon commented #376
  • Dec 12 21:34
    flash-gordon labeled #376
  • Dec 12 21:34
    flash-gordon opened #376
  • Dec 12 19:32
    RyanLafferty starred dry-rb/dry-types
  • Dec 12 05:53
    technofreak starred dry-rb/dry-monads
  • Dec 12 00:14
    thekuwayama starred dry-rb/dry-monads
  • Dec 11 09:29
    blasterun starred dry-rb/dry-monads
  • Dec 11 08:34
    flash-gordon closed #115
  • Dec 11 08:34
    flash-gordon commented #115
  • Dec 11 08:31

    flash-gordon on v1.3.3

    (compare)

  • Dec 11 08:30

    flash-gordon on master

    Bump version to 1.3.3 (compare)

  • Dec 11 08:30

    flash-gordon on master

    Update CHANGELOG (compare)

  • Dec 10 23:46
    johnmaxwell commented #116
  • Dec 10 21:54

    flash-gordon on master

    Halt with mutable backtrace Ex… Merge pull request #116 from jo… (compare)

  • Dec 10 21:54
    flash-gordon closed #116
  • Dec 10 21:54
    flash-gordon commented #116
  • Dec 10 21:49
    johnmaxwell commented #116
  • Dec 10 21:47
    johnmaxwell commented #116
  • Dec 10 21:43
    johnmaxwell commented #116
  • Dec 10 21:39
    johnmaxwell commented #116
Tim Riley
@timriley
Code should inform tests :)
(and if it makes testing too hard, well, that’s a code problem)
Jonah
@jonahx
@timriley, well, the test is perfectly easy. it’s just that rspec double’s aren’t designed with type checking in mind, which is fair enough given how atypcal it is in ruby. imo dry::struct types bring a certain sanity to ruby that should be there, but the fact remains it’s still an addon to the language, so to speak.
Tim Riley
@timriley
Yeah. I’d only use doubles where duck-typing matters more than the actual strict class check
Jonah
@jonahx
@timriley which is indeed the case here. i sort of added the class constraint just as a way of enforcing the interface, but now that you mention it i think that’s where my mistake was — the contract really is just an interface and not a particular class. and removing the type constraint which i’ve what i did to fix the issue was probably the correct move anyway and not just a hack as i’ve been viewing it
Tim Riley
@timriley
Cool :)
Alexander Chernik
@achernik
Hello!
I have a question regarding dry-validation usage. Is it possible to "filter out" invalid parts instead of flat out rejecting entire hash?
I could use result.errors to filter result.output manually, but maybe there is another way?
Jonah
@jonahx
How can I get an attribute that is both optional and default? I want to be able to leave it out, and when I do, it should have a default value.
Nikita Shilnikov
@flash-gordon
@jonahx I think it's what dry-types/dry-struct does in master, check out the changelogs
Tiago Moraes
@tiagoefmoraes

Hello,
when defining an enum without 0 as a valid value:

subject(:enum) { Dry::Types['integer'].enum(4, 5, 6) }

I expected that it would be invalid

expect(enum.try(0)).to be_failure

but it is actually valid because of inverted_mapping. I found this to be really confusing.
Should't this inverted behavior only happen when the mapping is defined explicitly?

subject(:enum) { Dry::Types['integer'].enum(4 => 0) }

At least when the values are all integers?

Nikita Shilnikov
@flash-gordon
it always worked like that for integers but I think this behavior can be made configurable
well, try didn't work in prev version actually but fixed this :)
[] worked
I would say it's better not to have mapping by default
but this is a breaking change
Nikita Shilnikov
@flash-gordon
@tiagoefmoraes I'll do what you suggested before the release, thanks for bringing it
Jonah
@jonahx

Any idea why I could be getting the error:

Attribute :authenticator_name has already been defined (Dry::Struct::RepeatedAttributeError)

when that is not the case?
My class looks like this:

    class Input < ::Dry::Struct
      attribute :authenticator_name, Types::NonEmptyString
      attribute :service_id,         Types::Coercible::String
      attribute :account,            Types::NonEmptyString
      attribute :username,           Types::NonEmptyString
      attribute :password,           Types::NonEmptyString
    end
Nikita Shilnikov
@flash-gordon
@jonahx most likely the file containing Input getting loaded twice
Jonah
@jonahx
@flash-gordon yep, rails was autoloading and there was a require statement somewhere. when i removed the require the error vanished.
Tiago Moraes
@tiagoefmoraes
@flash-gordon thanks!
Ryan Bigg
@radar
in ur repos, submitting PRs: dry-rb/dry-core#25
Jonah
@jonahx

How can I mix required and optional/default attributes? That is, the following works fine:

class Test < Dry::Struct
  attribute :optional, Types::Any.default('default value')
end
p Test.new.optional #=> prints 'default value'

However

class Test2 < Dry::Struct
  attribute :required, Types::Any
  attribute :optional, Types::Any.default('default value')
end
p Test2.new(required: 'my required val')
# Raises:
# [Test2.new] :optional is missing in Hash input (Dry::Struct::Error)
Jean-Denis Koeck
@jeandenis-k
Hi @jonahx ! Seems to me you would have to use, in the body of your class, either constructor_type :strict_with_defaults or constructor_type :schema
Jonah
@jonahx
@jeandenis-k thanks, i’ll try it
Jean-Denis Koeck
@jeandenis-k
:+1:
Jonah
@jonahx
Separate question. Consider:
class Test < Dry::Struct
  attribute :cls, Types::Any.default(String)
end

p Test.new.cls == String # return true
Yet in my actual code I’m doing the same thing with a Sequel class:
    attribute :resource_class, ::Types::Any.default(Resource)
but when I later access resource_class it returns not the class, but it seems an instance of the class:
#<Resource @values=#<#<Class:0x00000003e7bf00> primitive=Object options={} meta={}>>
Is there any magic the dry::struct does on class values for defaults that would explain this?
Jonah
@jonahx

Interesting…
The problem is fixed if I do

attribute :resource_class, ::Types::Any.default { Resource }

I wonder why those are different?

Jean-Denis Koeck
@jeandenis-k
Interesting, tried to find why in the source code of dry-types but I can't make head or tails of it :sweat_smile:
Andrea Tore
@nakedmoon
Hi guys, quick question: is there any way to have a dry-struct attribute like a Constructor Types::Hash with a default value ?
Andrea Tore
@nakedmoon
IntType = Types.Constructor(Types::Hash){|value| Types::Hash(:strict_with_defaults, int: Types::Form::Int)[int: value]}

class MyClass < Dry::Struct
constructor_type :strict_with_defaults
Andrea Tore
@nakedmoon
IntType = Types.Constructor(Types::Hash){|value| Types::Hash(:strict_with_defaults, int: Types::Form::Int)[int: value]}

class MyClass < Dry::Struct
  constructor_type :strict_with_defaults
  attribute int_attribute_one, Types::IntType.default(1)
  attribute int_attribute_two, Types::IntType.default(2)
end

2.3.3 :181 > MyClass.new()
TypeError: class or module required

using the block notation:

attribute int_attribute_one, Types::IntType.default{1}
attribute int_attribute_two, Types::IntType.default{2}

2.3.3 :188 > MyClass.new()
=> #<MyClass int_attribute_one={:int=>1} int_attribute_two={:int=>2}>
2.3.3 :189 > MyClass.new(int_attribute_one: 1)
=> #<MyClass int_attribute_one={:int=>1} int_attribute_two=2>
Nikolai Budko
@nibygro

Hi guys! I have a problem with dry-validations (0.11)

require 'dry-validation'

UserSchema = Dry::Validation.Schema do
  rule(value_filled: [:value1, :value2, :value3]) do |value1, value2, value3|
    value1.eql?('1') | value2.eql?('1') | value3.eql?('1')
  end
end

UserSchema.(
  value1: '0',
  value2: '0',
  value3: '0'
).inspect

# => "#<Dry::Validation::Result output={:value1=>\"0\", :value2=>\"0\", :value3=>\"0\"} errors={}>"

Why there are no errors for the schema? y rule is one of the fields must be filled with '1'

Nikolai Budko
@nibygro

Oh, I'v got it. I need to defined this properies as optional

But I think it's a little bit redundant..

Also if I define three optional properties, than I will get a strange error:
 => "#<Dry::Validation::Result output={:value1=>\"0\", :value2=>\"0\", :value3=>\"0\"} errors={:some_filled=>[\"must be equal to 1 or must be equal to 1\"]}>"
Ryan Bigg
@radar
dry-rb/dry-equalizer#9 I don't understand how / why this is different from dry-rb/dry-equalizer#8 but there you go. So very perplexed.
Turns out: I don't know Ruby.
Joshua Hansen
@binarypaladin
I can't tell if I've hit a bug or I'm using some kind of behavior incorrectly, but it seems to me there are oddities when using schema inheritance with schemas that are create with JSON or Form. Consider this:
Schema = Dry::Validation.Schema do
  configure { config.type_specs = true }
  required(:first_name, :string).filled(:str?)
end

OtherSchema = Dry::Validation.Schema(Schema) do
  required(:last_name, :string).filled(:str?)
end

input = { first_name: 'John', last_name: 'Smith' }
Schema.(input).success? => true
Schema.(input).output => {:first_name=>"John", :last_name=>"Smith"}
OtherSchema.(input).success? => true
OtherSchema.(input).output => {:first_name=>"John", :last_name=>"Smith"}

Schema = Dry::Validation.JSON do
  configure { config.type_specs = true }
  required(:first_name, :string).filled(:str?)
end

OtherSchema = Dry::Validation.Schema(Schema) do
  required(:last_name, :string).filled(:str?)
end

input = { 'first_name' => 'Joe', 'last_name' => 'Smith' }

Schema.(input).success? => true
Schema.(input).output => {:first_name=>"Joe"}
OtherSchema.(input).success? => false
OtherSchema.(input).errors => {:first_name=>["is missing"]}
I cannot seem seem to get OtherSchema to recognize first_name. Inheritance works as I would expect with the normal schema. It's not a problem with the JSON macro either, as this would yield the same issues:
Schema = Dry::Validation.Schema do
  configure do
    config.type_specs = true
    config.input_processor = :json
    config.hash_type = :symbolized
  end
  required(:first_name, :string).filled(:str?)
end

OtherSchema = Dry::Validation.Schema(Schema) do
  required(:last_name, :string).filled(:str?)
end
I thought perhaps explicitly setting configuration on both would do the trick, but no dice:
OtherSchema = Dry::Validation.Schema(Schema) do
  configure do
    config.type_specs = true
    config.input_processor = :json
    config.hash_type = :symbolized
  end
  required(:last_name, :string).filled(:str?)
end
Joshua Hansen
@binarypaladin
Setting input_processor is clearly the culprit when messing around with scenarios.
Any ideas on how to handle inheritance with with a preprocessor set?
Joshua Hansen
@binarypaladin

One more thing to add, it isn't just the input_preprocessor but rather a combination of that and type_specs set to true. Looking at OtherSchema I see that:

OtherSchema.config[:type_map] => {:last_name=>#<Dry::Types::Definition primitive=String options={} meta={}>}

Not that first_name is not in the type_map. I haven't done a deep dive into the code yet, but if anyone familiar with the finer points can give me any pointers (or just flat out tell me if this is a bug and, if so, I'll work to patch it) that would be really handy.

Joshua Hansen
@binarypaladin

Looks like the bug has actually been patched: https://github.com/dry-rb/dry-validation/pull/359/commits/71872da3985c54b6930ed39c42d004f837e9812f

This fixes the behavior. Is there something wrong with this PR?

if you want to use them with dry-validation, please stick to the master branch for now