dry-trasnaction v0.6.0 is released!
It has a big new feature - custom step adapters: http://dry-rb.org/gems/dry-transaction/custom-step-adapters/
I’ll be announcing in a blog post tomorrow :)
Nice one :)
nice :clap:
I felt like Martin Luther writing up dry-rb/dry-types#72
tl;dr:
Dry::Types::Struct.constructor_type is the Virtus of dry-types
Struct behaviour was originaly designed to work with ROM relations and mappers. So I wanted to make sure all data was fetched, but I didn't care about additional keys that were used for joining or whatever else
Makes sense
As I mentioned in the issue
And I never liked changing constructor behavior using this macro. I added it because people complained :P
heh
Well I think that the keys should just be treated like types
I will read 72 when I'm in the office. On mobile atm
kk
@backus :+1: it seems we're gone too far trying to address all possible issues with different constructors
Agree
Well, I only wanted to address 3 use cases I had in rom and dry-validation
@solnic hi! (I'm back again)
What is our policy for publishing to rubygems?
dry-initializer is waiting for release, but I'm not sure whether to publish it from my account, or somehow else
@nepalez hey, good to see you back
I wanted to discuss dry-initializer vs dry-constructor vs dry-types’ structs and what we’re doing with these projects, and what our intentions are. I’m actually concerned that we’re gonna create some confusion around these 3 projects
ie I would hate to see people using dry-initializer as a virtus replacement because I’m much more interested in shifting people towards dry-types heh
furthermore I was hoping to use dry-initializer instead of custom-made Options APIs that we have in both ROM and some dry-* libs
@solnic I completely understand your intentions but people will continue to ask questions about default/missing keys and type constraints if we wouldn't make it obvious how to configure desired behavior
but it seems like dry-initializer scope is way bigger
@flash-gordon well, we are sorting it out in dry-types, esp with @backus chiming in it should be simpler now as more people are collaborating and we all want to make things right
@flash-gordon what was your use case with dry-initializer?
replacing virtus’ or something similar?
Well. This project was exctracted by me from @marshall-lee
dry-function. Its scope was to replace virtus by something more efficient and safe.
ok, so we’re having an interesting conflict of interest here, because I created dry-types hoping to move people away from the virtus’ approach :/
its type system backs of
dry-types, but allows simple PORO types as well
@solnic are you asking me about dry-types or @nepalez about dry-initializer? :) I currently use it for models with ROM. But don't worry about me I already resolved all issues that I had :)
I gotta think it through, I mean I’m not against having dry-initializer in dry-rb ecosystem, don’t get me wrong. I just want to avoid confusion. We’re creating a new ecosystem with different philosophy than typical rails-like APIs, so we need to make sure things are clear from the start.
We discussed with @marshall-lee the dependencies between dry-initializer and dry-types. We decided that
dry-types should be core thing and dry-initializer to work on top of it
@AMHOL @timriley could you chime in please? ^
The only thing
It heavily uses new ruby 2.2+ hash arguments to make initialization as fast as possible
dry-initializer does is... well... initialization ;)It heavily uses new ruby 2.2+ hash arguments to make initialization as fast as possible
Hi there. I'll be able to read over this in an hour or so :)
And as @solnic mentioned above, a part of
dry-initializer is about extraction of options from rom-support
@flash-gordon if you use dry-initializer, notice that at the end I removed plain defaults from it, leaving
default: -> { ... } syntax only
this was done to avoid unintentional mutability of default variables after assignment
and waiting for this update is the only reason I didn't released
0.0.1 before
@nepalez currently I don't use it
@nepalez yeah I was hoping to use dry-initializer in rom and other places instead of rom-support stuff, in fact, I want to REMOVE rom-support and replace it with dry-* libs
recommended reading about ruby/elixir/ecto/ar/rails/dry-rb/trailblazer etc
@solnic pretty exciting read :+1:
@nepalez I’ve been looking at dry-initializer readme and I see way too much overlap between dry-initializer and dry-constructor AND dry-types. We should address this somehow
ie
default option should be dropped IMO and you should just define a type with default value, like in dry-types structs
also really mixed feelings about
:writer option
best to remove this, people can add writers themselves, or even add a custom extension to support this
less code to maintain, esp that we all don’t use writers
@solnic Thank you! I'll see it at the evening. @marshall-lee what do you think about it? ^^
now,
param and option are fantastic, I can use exactly this in many many places
attr_hash is also too much for me, and it creates confusion that these type of objects are hash mappers at the same time
I think these changes would certainly make the library feel clearer and more approachable.
As well as fit in better with the existing ecosystem of dry-rb gems.
yes, we gotta make it fit better, feels too detached right now, and api feels too big
oh and would be cool if it could use dry-constructor
we need dry-constructor in dry-auto_inject
or maybe we need dry-initializer in dry-auto_inject?! geez
I'm agree about attr_hash, and will remove it today. Concerning defaults, I feel I have to know more about dry-types. I'll reed it and make a decision.
Still not sure about reader and writer. From the one hand, I'm agree - initializer is a separate feature. But from the other, I look at the initializer as an instance dependency injector, and would prefer those dependencies to be readable. Maybe it makes sense to keep reader and drop writer
reader should stay, enabled by default
writer is awful ;)
default types are trivial to use:
Types::String.default(“foo”)
plain assignment? hmm... I need to check if it mutation-safe
whatever, I agree: we should not to multiply defaults
@guizmaii hey, sorry for not replying yesterday, day was kinda rough for me. Anyhow, I wouldn’t recommend using AR models as values in a plain ruby struct, the intention is that these objects are very simple, and AR objects is the opposite of simple :)
@guizmaii and thank you for your kind words <3
@Bounga still here?
@solnic Yes
Hi everyone, I'm unclear on the difference between Dry::Types::Struct and Dry::Types::Value -- what features does one have that the other doesn't? The documentation is clear on their similarity but not their differences!
You can define value objects which will behave like structs and have equality methods too
oops, this is outdated doc
now both structs and values have equalizer mixed in, but values are being frozen on initialization
ahh! got it - thanks. will play with it to let it sink in :) BTW, the documentation was on: http://dry-rb.org/gems/dry-types/struct-and-value/
@solnic Did you find out what was wrong?
@Bounga first of all,
schema syntax won’t work with “models”
it’s designed to work with hashes exclusively
in fact
schema applies hash? predicate automatically
if your intention is to validate a model with attr readers, we have
attr DSL instead of key
support for models is worse than hashes, I should warn you about that
in general I recommend using hashes, not models
for embedded models, you can nest
attr DSL, it should work
in the near future we should introduce something like
attr(:foo).model { … }
I think I'm feeding
schema.call with a hash (with nested hash). Not sure to understand the problem
oh, sorry, so you are using hashes
for some reason I thought you’re using entities with attr readers
Did you see this example ? https://gist.github.com/Bounga/36875ef3201d2406821c9d48f5890874
it illustrates my problem
wait, so
type is not a hash
As you can see, I'm feeding the call with a hash
You're right, in this case, this is not. But in fact in my real code I have a
to_hashmethod that creates a hash (with nested hashes) to feed the callmethod
as you can see, the
Entity.new only uses strings and a hash.
@Bounga seems like a bug :(
#<#<Class:0x007fa07a81cbb8>:0x007fa07a8a5b98 @rule_compiler=#…. this is so awful, I gotta do something about that
@solnic what was kinda weird for me was that I could only use
I quite like pry driven development when discovering a new lib
binding.pry in the custom predicates I defined.I quite like pry driven development when discovering a new lib
for example:
require 'dry/validation'
require 'pry'
SCHEMA = Dry::Validation.Schema do
binding.pry
endalso doing some puts in there or smth else never executes, so I doubt that the block is actually ever executed? :D
@tak1n huh?
test.rb:5:in `block in <main>': undefined method `pry' for #<Dry::Validation::Schema::Rule:0x0056432b6dd048> (NoMethodError)
from /home/benny/Dev/onlim/adapter/.gem/ruby/2.3.0/gems/dry-validation-0.7.3/lib/dry/validation.rb:23:in `instance_exec'
from /home/benny/Dev/onlim/adapter/.gem/ruby/2.3.0/gems/dry-validation-0.7.3/lib/dry/validation.rb:23:in `Schema'
from test.rb:4:in `<main>'
shell returned 1
the dsl is a basic object
use byebug instead
or
require 'dry/validation'
require 'pry'
SCHEMA = Dry::Validation.Schema do
puts 'hi'
end::Kernel.byebug
the dsl context is a basic object, these methods are not available
kk
Kernel.puts 'hi' works, thx for that hint :D
is this somewhere documented otherwise I will create some docs stating that
just was somehow surprising for me
it’s not documented
k, should this be documented, I mean maybe it was just surprising for me :D
using BasicObject is not a common thing to do
it’s mostly useful for DSLs
kk
@Bounga I fixed it in master, you can try it out by installing dry-v from github
sooo I just wrote this in a Struct class:
# Hack to make things writable with type checking
def self.attributes(new_schema)
super
new_schema.keys.each do |k|
define_method("#{k}=") do |value|
instance_variable_set("@#{k}", self.class.schema[k][value])
end
end
end:scream:
:runner:
eternal :fire: awaits you
:D
:clap:
yay
FYI
how long?
(Approximately of course)
@backus not sure tbh, but not too long, few weeks probably
oh lol k
last time I think I managed to be “away” for like 6 weeks
;(
wtf?
Exactly. Just rails mindset
Good morning. I’m going to write a blog post announcing dry-transaction v0.6 and the custom step adapters this morning.
@solnic I hope you have a good break! We’ll miss you.
@timriley thanks
@solnic my followup comment on #72 (and the discussion in general) is the main thing I want to resolve before you begin your OSS break
Since the outcome decides whether our team will need to build some functionality on top of dry-types for internal use
Yes I want to address this before I "go"
FWIW, the main thing I care about is being able to have a truly strict struct with dry-types
In that I want to just be able to say "only symbol keys, fail if there are unexpected keys, fail if keys without defaults are omitted"
But I'm adapting my needs to try to recommend more general solutions for the sake of the project
why would you be so strict about keys?
and I’m OK with a super-strict struct
I didn’t have a use-case for that yet but I can see how this could be useful
btw what’s your use case for srsly-strict structs?
@backus ^
Woop sorry
Well in general it means that a little less magic is happening when I'm initializing a new object and that is attractive to me for the same reasons that any of the anti-magic aspects of dry-rb are attractive to me
I prefer that, if keys are being dropped, it is being done explicitly. Same reason I prefer that a value be explicitly type cast via a declaration in a
Dry::Types::Struct as opposed to done automatically for me by something like Active Record
where are you going to have that dropping keys part?
Then that boils down to two separate motivations.
- Developer sanity. In general if I see
UnknownAttributeError :fooinstead ofundefined method 'foo'I'm less likely to spend time tracking down what went wrong because the error is more clear
- Catching mistakes handling user input in production. We build APIs and if we process an API request with invalid keys by silently dropping that key on some object initialization then all of the sudden that is behavior that customers might have in their production apps that we can't change without breaking their compatibility
:/ I guess gitter wants to make both of those "1." whatever
markdown
would’ve been 2 if you posted it in one message
mhm
I get the second 1 ;)
you messaged in the middle of me typing it up though and I know it is like 1AM for you so I wanted to keep your attention :P
I want to introduce a feature in dry-v where unexpected keys are reported as rule violations
That would be great
@solnic any chance you could cast a quick eye over this? https://github.com/dry-rb/dry-rb.org/blob/128eaf61803193082bd18473e00d62fb7f3bf95c/source/news/2016-04-07.html.markdown
Once we get to the dry-validation part of our new API, if that didn't exist, I would be nagging about that too :laughing:
I want that myself fwiw
@timriley casting
@solnic thanks! I appreciate it, given the hour :)
@timriley looks good, great to see it released :)
Thanks! I’ll make a few little tweaks of my own and publish shortly :)
@timriley since it’s the first post about dry-transaction, maybe a super quick intro in the first paragraph would be good? like what it is etc?
That’s a good idea.
dry-transaction is dry-rb's answer to modelling complex business transactions in your applicartions. With dry-transaction, you can arrange multiple processing operations into a linear pipeline, with the output of each step becoming the input of the next.
^ @solnic do you reckon that’s good enough for a throwaway intro?
@timriley :+1: and maybe one more sentence about error handling being 1st class feature
you’re a 1st class feature
timriley @timriley adds it
:laughing:
dry-transaction is dry-rb's answer to modelling complex business transactions in your applicartions. With dry-transaction, you can arrange multiple processing operations into a linear pipeline, with the output of each step becoming the input of the next. dry-transaction also elevates error handling to a first-class concern. Any error will halt the flow of operations, and you have powerful APIs for matching and acting on errors.
@solnic cover it well enough?
@timriley :+1:
woot! Doing this.
just do it
strangely, my article doesn’t come through when the site is built
@timriley how did you deploy?
be middleman deploy
it’s
middleman deploy
ok
this issue is showing itself when I just
be middleman build locally too
the new article doesn’t get built
@timriley worked for me
deploying
Thanks :weary:
hmm, don’t see it
weird, hey? it shows up when I just
be middleman and visit the server
maybe gh pages are having issues
wait no, it’s not being built