Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Piotr Solnica
@solnic
hah :)
Kareem Hepburn
@magicalbanana
@solnic where I work that gt? would never fly. They emphasize on convention here (the rails one) too much. :(
@solnic so is dry-validations stable?
Piotr Solnica
@solnic
no, it’s 0.4.2 atm
will push 0.5.0 later today or tomorrow
Kareem Hepburn
@magicalbanana
Ah, how long before you think it becomes stable?
Piotr Solnica
@solnic
I’ll release 1.0.0 once I’m done with error message compilation optimizations
it’s my personal pet peeve :joy:
targeting February for 1.0
Kareem Hepburn
@magicalbanana
I get that. I think I’ll start doing benchmarks for all the validators I am aware of. Should be good.
Piotr Solnica
@solnic
dry-data 0.5 and dry-validation 0.5 were released and now they both depend on the new dry-logic gem
@kwando I added "default value” support in this release, I remember you asked about a DSL for that the other day…it’s a bit different than in virtus and currently only supports a simple value, so no procs or method names are supported
Tim Riley
@timriley
An interesting thing I’m seeing with the rodakase apps we have and these container-based gems with finalization (i.e. rom and dry-data now, with its types module) is that if you want 2 distinct places for registering entities with those gems (i.e. in our rodakase app we have “main” and “admin” sub-apps) then it becomes pretty hard to do.
since the finalization needs to somehow span the boot sequence of both of the sub-apps. Or perhaps they ideally have their own containers/namespaces, which isn’t quite possible with those gems, I think.
Piotr Solnica
@solnic
"Entities" being?
Tim Riley
@timriley
ah, so whatever the gem’s concerned with registering: relations, commands, mappers, etc. for rom and then type definitions for dry-d
Tim Riley
@timriley
I think in dry-d’s case it’s not too bad. I’d just configure a top-level Types namespace globally in the app, then use modules underneath that if any of the sub-apps need specific types defined.
The finalizing bit might be tricky still. Let me look at the code.
Andy Holland
@AMHOL
@solnic we spoke about maybe doing something like this rather than the finalize/namespace configuration, don't know if you remember?
module Dry
  module Data
    def self.register_types(mod)
      define_constants(mod, container._container.keys)
    end
  end
end
Tim Riley
@timriley
Making it an explicit thing you can do a number of times?
Andy Holland
@AMHOL
Then you can do:
module Core
  module Types
    Dry::Data.register_types(self)
  end
end
@timriley yeah
Tim Riley
@timriley
I like that approach.
Andy Holland
@AMHOL
Me too :)
Piotr Solnica
@solnic
there’s no need for that, types are objects, assign them to constants and you’re done
the finalization is there so that dry built-in types are defined within your namespace
Tim Riley
@timriley
Ah, right.
Piotr Solnica
@solnic
we can provide default namespace that you can just include it
include Dry::Data::Types::BuiltIn or something
Piotr Solnica
@solnic
@timriley re configuring deps, you're talking about deps that are places in diff subapps but share common booting code?
Tim Riley
@timriley
In this case they share common boot code (relations), yeah. My situation was that I thought I’d need a mapper in a sub-app to map to one of its own entity classes – turns out I don’t, so I’ve avoidede the issue for now.
Piotr Solnica
@solnic
I am working on improving this. Ie it is possible to define rom as a standalone component shared between subapps. So it is not part of the booting process of any app
Tim Riley
@timriley
ah, interesting
Piotr Solnica
@solnic
So anything that requires rom and some of its components, can define it as a dep and it will trigger its booting etc
Tim Riley
@timriley
How would the finalization of rom’s own container work there?
Piotr Solnica
@solnic
When you require it through dry-component it will trigger its booting so it will create its container etc
Tim Riley
@timriley
the dry-component container, or rom’s own internal container?
The issue I was foreseeing (which I haven’t hit in real life, yet) is when rom comes in a shared component for the shared things, but subapps also add their own specific things (i.e. mappers, maybe even relations or extra commands etc.) is that you’d need to somehow delay finalizing rom until everything had booted
Piotr Solnica
@solnic
I will try a setup like that and make it work
It boils down to sharing the same gateway instances across entire app between its subapps
Piotr Solnica
@solnic
       user     system      total        real
DV: 1 thread 10.610000   0.170000  10.780000 (  3.519302)
AM: 1 thread 18.670000   0.240000  18.910000 (  7.975311)
DV: 2 threads  3.280000   0.050000   3.330000 (  0.911350)
AM: 2 threads  7.950000   0.090000   8.040000 (  3.307048)
multi-threaded validation of 10k hashes on jruby O_O
Tim Riley
@timriley
nice!
Piotr Solnica
@solnic
3 x faster on dry-v with 1 thread vs 2 threads
and 1 thread is faster than 2 threads on MRI
...
lemme gist it
Oskar Szrajer
@gotar
it's quite normal i guess -- java
Piotr Solnica
@solnic
yeah it is