dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

Ryan Bigg

@radar

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?

Nikita Shilnikov

@flash-gordon

https://twitter.com/NikitaShilnikov/status/992059914817335298

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

Chris Richards

@cmrichards

hmm.. get this error in the rails console but the code works just fine when running the server: "LoadError (cannot load such file -- dry-struct)"

Nikita Shilnikov

@flash-gordon

what's the stacktrace?

Damien Timewell

@idlefingers

Hey guys, I'm upgrading a project I'm working on to the most recent dry-types and dry-struct and trying to understand how to deal with the removal of constructor_type. Can someone point me in the direction of how to make all attributes omittable, without explicitly having to set .meta(omittable: true)? I used constructor_type :schema to get around it before..

Gustavo Caso

@GustavoCaso

Hi @idlefingers

I think this will do the trick

class User < Dry::Struct
  transform_types do |type|
    type.meta(omittable: true)
  end

  attribute :name, Types::Strict::String
  attribute :age,  Types::Strict::Integer.default(18)
end

Please let me know if that solved the problem

Damien Timewell

@idlefingers

Ahaaaa, I get it. It works! Perfect, thanks a ton for your help @GustavoCaso :)

Gustavo Caso

@GustavoCaso

My pleasure :smile:

Damien Timewell

@idlefingers

Hmmm, but now the meta is included in Hash values :/ ...

class User < Dry::Struct
  transform_types do |type|
    type.meta(omittable: true)
  end

  attribute :foo, Types::Hash.default(Hash.new)
end

User.new.foo # => {:meta=>{:omittable=>true}}

Gustavo Caso

@GustavoCaso

class User < Dry::Struct
  transform_types do |type|
    type.optional
  end

  attribute :name, Types::Strict::String
  attribute :age,  Types::Strict::Integer.default(18)
end

Could you try that one?

Damien Timewell

@idlefingers

That just means it can be nil, but the key is still required, right?

Dry::Struct::Error: [User.new] :name is missing in Hash input

Gustavo Caso

@GustavoCaso

You can set a deafult value if what you are looking is for avoid the meta

Does it helps you? @idlefingers

Damien Timewell

@idlefingers

I'm not sure I follow. In the example class I pasted above, I set the default to be a new hash, but when the class is initialized, that hash includes became {:meta=>{:omittable=>true}}

so instead of User.new.foo # => {:meta=>{:omittable=>true}} I'm trying to get User.new.foo # => {} (which is what constructor_type :schema did before)

Gustavo Caso

@GustavoCaso

All your attributes are hashes?

class User < Dry::Struct
  transform_types do |type|
    type.optional.deafult({})
  end

  attribute :foo, Types::Hash
end

Damien Timewell

@idlefingers

No, they could be anything

Gustavo Caso

@GustavoCaso

I think this will do trick for that case you mentioned

Damien Timewell

@idlefingers

I don't think that will work :( It needs to be able to handle any type

Gustavo Caso

@GustavoCaso

@idlefingers how about this to avoid the extra meta attribute

class User < Dry::Struct
  transform_types do |type|
    if type.default?
      type
    else
      type.meta(omittable: true)
    end
  end
  attribute :foo, Types::Hash.default({})
  attribute :bar, Types::String
end

User.new
=> #<User foo={} bar=nil>

Damien Timewell

@idlefingers

nice! Seems to work. Will test around some more

Gustavo Caso

@GustavoCaso

Sure let me know if you need anything

Damien Timewell

@idlefingers

thanks

Gustavo Caso

@GustavoCaso

your welcome

Nikita Shilnikov

@flash-gordon

this looks like a bug to me, something's not quite right with defaults where

Gustavo Caso

@GustavoCaso

@flash-gordon I'm happy to have a look

Gustavo Caso

@GustavoCaso

@idlefingers I have open a PR fixing the issue dry-rb/dry-types#250

Damien Timewell

@idlefingers

Awesome @GustavoCaso. So with that change, this should work?

transform_types do |type|
  type.meta(omittable: true)
end

Gustavo Caso

@GustavoCaso

It should work I will try running more test with dry-struct

Damien Timewell

@idlefingers

:thumbsup:

Gustavo Caso

@GustavoCaso

but if you want to try and let me know that would be great

Nikita Shilnikov

@flash-gordon

I wouldn't call meta on defaults anyway, it doesn't make sense to me

@idlefingers don't forget, you can create a base class if you don't want to call transform_types many times

Where communities thrive

People

Repo info

Activity