danielsdeleo / deep_merge Goto Github PK

Hi, thanks for the cool gem 8)

So, there's a feature suggestion, it would be nice to allow passing a block to be yielded when there's a conflict not in Hash or Array lets say, as Rails deep_merge and Hash merge do. It could serve for things like doing calculations and such or allowing the decision to override a value to be done in other ways, in my use case, I wanted to sum one of the values.

I'll probably try coming up with a monkey patch for my purposes, I'll say already I'm very lazy but I could try coming up with a pull request, specially if the feature is desirable.

hash1 = { a: 1, b: 2 }
=> {:a=>1, :b=>2}

hash2 = { a: 3, c: 4 }
=> {:a=>3, :c=>4}

hash1.deep_merge(hash2)
=> {:a=>1, :b=>2, :c=>4}

hash1.deep_merge!(hash2)
=> {:a=>3, :b=>2, :c=>4}

This difference in behaviour seems counterintuitive. Usually the bang method is the destructive equivalent of the non-bang method returning the same result.

I want the behaviour of deep_merge! above where :a's value is overwritten but I don't want to apply it destructively to the original hash1 object. Can this be done?

Would it be possible to bump for a new release with the addition of the keep_array_duplicates? I know there hasn't really been anything else added since the merge back in August, but I'd love to use this feature.

Thanks!

Something like require 'deep_merge/core_ext' and without it you could use DeepMerge.merge(hash1, hash2) or hash1.extend(DeepMerge::Hash).merge(hash2)

When you tag releases, would you mind pushing the tags to GitHub? For example the latest version on Rubygems.org is 1.0.1, but the 1.0.1 tag is missing from the repository.

Given that the Hash#merge method does not modify the receiver hash, I think it's really confusing that Hash#deep_merge does.

For#merge:

irb --simple-prompt merge.rb
>> h = {}
=> {}
>> h.merge(m: 1)
=> {:m=>1}
>> h
=> {}
>> h.merge!(m!: 2)
=> {:m!=>2}
>> h
=> {:m!=>2}

but for #deep_merge:

irb --simple-prompt deep_merge.rb
>> require 'deep_merge'
=> true
>> h = {}
=> {}
>> h.deep_merge(dm: 1)
=> {:dm=>1}
>> h
=> {:dm=>1}
>> h.deep_merge!(dm!: 2)
=> {:dm=>1, :dm!=>2}
>> h
=> {:dm=>1, :dm!=>2}

I see that #deep_merge! does have different behaviour for unmergeables, but I wonder if instead of using a ! suffix, is should instead use a prefix, in a similar manner to ko_deep_merge!, for consistency within this library.

Overall though, I think consistency with the stdlib is important, and therefore #deep_merge should not modify the receiver hash. As a test, I think this should not raise (as it currently does) {}.freeze.deep_merge(a: 1).

Hi,

I'm facing a strange behavior with keep_array_duplicates option when destination hash is empty.
To illustrate I picked up the unit test case and changed hash_dst initial value to {}

hash_src = {"item" => ["2", "3"]}
hash_dst = {}
DeepMerge::deep_merge!(hash_src, hash_dst, {:keep_array_duplicates => true})
puts hash_dst

It produces:

{"item"=>["2", "3", "2", "3"]}

I was expecting something like :

{"item"=>["2", "3"]}

Am I wrong?

When I use deep_merge with rails it messes up a couple of things like routing. In the documentation you mention that you should require 'deep_merge/rails_compat'.

When I do that using bundler however, my routing is still messed up. I assume bundler requires the gem automatically during bundler/setup, so the breaking code is still included.

Is there another way to use the gem with bundler? Thanks!

deep_merge behaves different than Hash#merge, where Hash#merge overwrites a key's value of the original hash if the hash being merged in contains the same key. The opposite is true for deep_merge.

$ ruby -v
ruby 2.0.0p451 (2014-02-24 revision 45167) [x86_64-darwin13.1.0]
$ irb
irb(main):001:0> require 'deep_merge'
=> true
irb(main):002:0> { key: 'left' }.merge({ key: 'right' })
=> {:key=>"right"}
irb(main):003:0> { key: 'left' }.deep_merge({ key: 'right' })
=> {:key=>"left"}

Is this as intended, or is this a bug in deep_merge?

Please see the failing spec here: #45

Is it possible to deep merge this
{:available=>{:inventory=>{:sordernum=>849836}}}
{:available=>{:inventory=>{:sordernum=>221836}}}

to produce
{:available=>{:inventory=>[{:sordernum=>849836},{:sordernum=>221836}]}}

{a: {b: 1}}.deep_merge(a: {b: 2}) returns {:a=>{:b=>1}}

... using https://github.com/mcrossen/deepsort now which behaves as expected

Hello,
My org uses deep_merge for Puppet 6.x.

The last release of deep_merge -- https://rubygems.org/gems/deep_merge/versions/1.2.1 -- was back in Nov 2017.

My org's security team prohibits the use of libraries which are not updated recently.

Can it be possible to release a newer version of deep_merge, so that we are in compliance?

Thank you!

As for the subject, it seems there is no way to use DeepMerge::deep_merge

def test_deep_merge
  old = {:foo => "hello"}
  new = {:foo => ""}

  DeepMerge.deep_merge!(new, old)
  assert_equal "", old[:foo]
end

I would expect old[:foo] to be an empty string here. But it doesn't seem to be. Am I doing something wrong?

To my surprise duplicate array elements were not duplicated.
Only by looking into the source code I did see that there was an option for it.

I suggest to add it the the main documentation as well

Hi, here is what I am seeing every time my rails app starts:

/[...]/gems/deep_merge-1.0.1/lib/deep_merge/core.rb:5: warning: already initialized constant DeepMerge::DEFAULT_FIELD_KNOCKOUT_PREFIX
/[...]/gems/rails_config-0.4.2/lib/rails_config/vendor/deep_merge.rb:4: warning: previous definition of DEFAULT_FIELD_KNOCKOUT_PREFIX was here

My Gemfile:

gem 'deep_merge', require: 'deep_merge/rails_compat'

Source:
"DeletionPolicy": null (JSON Style, in ruby its nil ;-)
Destination:
"DeletionPolicy": "Snapshot"

Destination.deep_merge!(Source, {:merge_nil_values => true})

Debug:
==>merging: :DeletionPolicy => nil :: "Snapshot"

Any way we could make this a gem, or get these changes merged into the deep_merge gem?