Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 09:39
    flash-gordon commented #97
  • 06:26

    solnic on main

    Rely on dry-core autoloading (compare)

  • 00:30
    ahoward commented #97
  • Jul 05 10:29
    nepalez starred dry-rb/dry-types
  • Jul 03 11:41
    cuilei5205189 starred dry-rb/dry-monads
  • Jul 02 11:26
    flash-gordon commented #97
  • Jul 01 09:55
    solnic opened #441
  • Jul 01 09:54
    solnic opened #242
  • Jun 30 17:02
    ahoward commented #97
  • Jun 30 17:01
    ahoward commented #97
  • Jun 30 16:58
  • Jun 30 09:01
    flash-gordon commented #97
  • Jun 30 03:07
    ahoward labeled #97
  • Jun 30 03:07
    ahoward opened #97
  • Jun 30 03:07
    ahoward labeled #97
  • Jun 28 13:44
  • Jun 28 10:17
    kroolp commented #83
  • Jun 28 07:49
    solnic commented #83
  • Jun 28 07:47
    solnic commented #84
  • Jun 27 16:07
    kroolp review_requested #84
Max Kuzmin
@maximkuzmin
hi there!
i'm kinda newby with dry-rb and wanted to use dry-types for my pet-project
i used to use rails autoload but now it's sinatra and i have some issues with loading all my types module
is there any way to not implement all rails autoload system Doppelganger and still not write all relative imports by hand?
Vasily Kolesnikov
@v-kolesnikov
Yes, it is. Look at dry-system.
Alfonso Uceda
@AlfonsoUceda

Hi folks, I'm experiencing a weird behaviour with rules, it seems they aren't nested and
they always are in the high level, take a look:

inner_schema = Dry::Validation.Schema do
  required(:vendor)    { type?(String) & filled? }
  required(:starts_on) { type?(String) & filled? }
  required(:ends_on)   { type?(String) & filled? }

  rule(time_range: [:starts_on, :ends_on]) do |starts_on, ends_on|
    ends_on.gt?(starts_on)
  end
end

schema = Dry::Validation.Schema do
  required(:contract).schema(inner_schema)
end

schema.call(contract: {vendor: '', starts_on: '2019-01-01', ends_on: '2018-01-01'}).messages
# => {:contract=>{:vendor=>["must be filled"]}, :time_range=>["must be greater than 2019-01-01"]}

inner_schema.call({vendor: '', starts_on: '2019-01-01', ends_on: '2018-01-01'}).messages
# => {:vendor=>["must be filled"], :time_range=>["must be greater than 2019-01-01"]}

is this a bug?

Spencer Goh
@dymaxionuk
I'm trying to unit test a dry transaction, however several problems.
Spencer Goh
@dymaxionuk
The transaction steps normally dynamically look up the operations from the container, however in spec, I'm manually instantiating the transaction, and passing a double into the constructor... But the original operation is being resolved instead... Am I supposed to use the container stub, instead of manually injecting a double?
Spencer Goh
@dymaxionuk
Ah mea culpa, <delete above! > the problem is actually my inability to stub a transaction step, which is defined locally in a transaction class. Sorry can't type example easily on mobile phone. def mylocalstep... expect(transaction).to receive(:mylocalstep).and_return(blah)
Doesn't seem to intercept the transaction step... Would be good to have a comprehensive set of testing examples for the dry family ....
Spencer Goh
@dymaxionuk
allow_any_instanceof(MyTransactionClass).to receive(:mylocalstep) does work. By not the above... Is there some magic going on?
Piotr Solnica
@solnic
@dymaxionuk expect-to-receive doesn't stub methods
Guilherme Moreira
@gmmoreira
IMHO if the step is defined locally in the class I would not stub it, otherwise I'm not testing all the behavior in my class. I would only stub operations injected by the container..
Piotr Solnica
@solnic
yes this

I'm manually instantiating the transaction, and passing a double into the constructor... But the original operation is being resolved instead

this looks like a bug, btw

Spencer Goh
@dymaxionuk
@solnic on the injection of double, I had a typo on the instance variable name. No bug oops
The reason I'm subbing out one of the steps (2nd step), is that the first step basically exits fast, on certain condition. So I only want my test to check that on one condition the second step is called, as other condition the second step is not called.
The downside of allowing my second step to be executed fully, is that it then pulls another operation from my container... That operation then auto injects some repos etc and the injection then forced me to pull in my db spec helper instead of just vanilla spec helper. I don't need to test such a bit surface area in this case.
Spencer Goh
@dymaxionuk
In testing that full code path for step two in my full end to end tests, as there is little value unit testing that. So bottom line is I should be able to do: ```expect(transction).to receive(:blah_step).and_return(dummy_data)
Piotr Solnica
@solnic
maybe it's using method objects, so rspec expectation can't work with it, not sure
@dymaxionuk Sounds like you’ve hit this issue? dry-rb/dry-transaction#75
Someone has promised to fix it, but they’ve taken months. I’ll see if I can do it myself sometime soon (or I’d be happy if you wanted to have a go, too!)
Jonah
@jonahx
:thumbsup: to new release!
@flash-gordon ^
Vasily Kolesnikov
@v-kolesnikov
:+1: :clap:
Nikita Shilnikov
@flash-gordon
pretty cool huh :)
Gustavo Caso
@GustavoCaso
:clap: :clap:
Spencer Goh
@dymaxionuk
Thanks @timriley wish I had time to explore, between slaving away at work and looking after baby, not much time left! I'll have a look if I get a breather.
On another note, is anyone interested in a trace/debug logging default for the dry transaction program flow? Given that the shape of the data will change significantly between each operation, and not all Failure states are necessarily triggered by Exception/Error, it can be useful in DEV deployment to have more colour over what caused failures. When one can't debug locally.
Spencer Goh
@dymaxionuk
I have an issue with an intermittent failure in a test, which doesn't manifest locally but only on the CI server. The output of roda flow driven dry transaction is returning a monad with True class as value. The only logging is the final backtrace in the router. But I would be useful to see the data and program flow along the whole execution path of the transaction, into it returns to route
70% of the time it returns my intended value object ... I can track it down but might be nice to have a trace feature. Any other use cases other people have across like this? Do you just add a ton of hand crafted logging manually?
Maybe option trace_transaction, true
Gustavo Caso
@GustavoCaso
I'm not a very experience dry-validations user but I wanted to share a question regarding some bahaviour I found for error messages
Having this schema
BusyPeriods = Dry::Validation.Schema do
  each do
    schema do
      required(:start_date).filled(:date?)
      required(:end_date).filled(:date?)
      required(:utilisation).filled(:int?)

      rule(started_before_ended: [:start_date, :end_date]) do |start_date, end_date|
        end_date.gt?(value(:start_date))
      end
    end
  end
end
If I try to validate some data if the error is related with the required attributes I will get a message with the format { index => error_message } but if the error comes from the rule I will get just the error with out the index. Is that expected?
{0=>{:utilisation=>["must be an integer"]}}
{:started_before_ended=>["must be greater than 2018-03-21"]}
Piotr Solnica
@solnic
@GustavoCaso end_date.gt?(start_date)
Gustavo Caso
@GustavoCaso
Thanks @solnic
Christian Meier
@mkristian
hi, found some in the issue of dry-validation how to reuse a Schema for nested arrays. wanted to extend the documentation a bit, is it to make a PR against: https://github.com/dry-rb/dry-rb.org ?
looks like autogenerated somehow !
Aaron Barthel
@abrthel
@mkristian from that link, then follow this folder path source > gems > dry-validation From there you just have to edit the markdown files
Christian Meier
@mkristian
ok - thanks. and I leave gz file as is ?
Aaron Barthel
@abrthel
under docs? Yeah you dont need to alter them at all. The markdown files get rendered into the actual deployable site.
Nicolas Cavigneaux
@Bounga
Hi there. I'm playing with Dry Types and I'm wondering if it is possible to do something like Types::Strict::String.constrained(filled: true) ?
Gustavo Caso
@GustavoCaso
Absolutely you can
Nicolas Cavigneaux
@Bounga
Is this the right syntax ?
Gustavo Caso
@GustavoCaso
Yes