I like it, just amend the CHANGELOG please, and I'll keep this open for a bit, lets see what others say.

Very timely for me! I was just poking around for solutions to this. Specifically, the ability to merge into the root hash. The one question I have, is what's the behavior on key collision, and can I control it. One idea is to support specifying a lambda to merge, and have it work like Hash#merge's block params:

expose :custom_attrs, merge: -> (k, v1, v2) { v1 }

I think this would do the trick -- in the OutputBuilder class:

if exposure.for_merge
  if exposure.for_merge.respond_to? :call
    @output_hash.merge! result, &exposure.for_merge
  else
    @output_hash.merge! result
  end
else
  @output_hash[exposure.key] = result
end

Hi @uberjay .
Default behaviour is just to merge! it. So a new key replaces old one. I think to use lambda is a good idea.

I am going to merge this.

See what I did there? Merge ...

👍

@avyy Looks like this introduced a regression, can you please check out #213?

@dblock ok I'll check it a bit later 👍

Any update on this? Just spent a lot of time chasing my tail due to this. I recommend pulling 0.5.1 or reverting this until it is resolved. This is a breaking change for more than just testing.

It breaks the wrapping of error messages in error! calls when using an entity model because the result returned to the present algorithm is no longer a Hash.

@wleeper I working on this. Tomorrow I let you know if it's really better to revert that commit 🎱

I don't think yanking 0.5.1 now is a good option, there're lots of people using it in production and it doesn't break "everything". Looking forward to a fix.

Any news?

@lucaskanashiro Looking forward to your PR!