| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Elasticsearch gems heavily integrate with Hashie. This leads people to want
to use a Mash as the backer for an Elasticsearch model, but the behavior is
different than they expect. By having this integration spec, we're covering two
things:
1. It might help ensure that we don't break the Elasticsearch ecosystem with
changes in Hashie as has happened in the past.
2. It communicates some gotchas that happen with using a Mash as the backer for
an Elasticsearch model.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Definition: Codependent properties
A set of two or more properties who have "required" validations that are based
on each other.
Example:
```ruby
class OneOrMore < Hashie::Dash
property :a, required: -> { b.nil? }
property :b, required: -> { a.nil? }
end
```
When constructing a Dash via the merge initializer, codependent properties have
their "required" validation run too early when their values are set to `nil`,
which causes an `ArgumentError` to be raised in the case that the first property
is set to `nil`.
This is an order-dependence bug that is fixed by this commit. By pruning off
`nil` values only during initialization via the merge initializer, we can
prevent this problem from occurring for the case of `nil` values.
However, this is an indication of a larger problem with the architecture of
Dash. We should be setting all the properties before running the validations.
Rearchitecting this will be quite an undertaking.
|
| |
|
|
|
|
|
|
| |
During non-destructive merges (i.e. `#merge`), the `IndifferentAccess` mixin was
failing to inject itself into the resulting Hash. This caused a `NoMethodError`
to be thrown when attempting to perform the action.
Now, we properly inject the mixin when necessary so the `#merge` method works.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case where you want to set deeply nested values through chained calls to
the `#[]` method or through method accessors (without using the bang methods),
you might set a `default_proc` on a Mash that recursively creates the key as you
access it. Previously, the `default_proc` was not being propagated down to
sub-Hashes because the way that `#dup` was written wasn't passing the
`default_proc` do the duplicated object.
Now, the `default_proc` is correctly being sent to the duplicated object, which
allows this pattern to work:
```ruby
h = Hashie::Mash.new { |mash, key| mash[key] = mash.class.new(&mash.default_proc) }
h.a.b.c = :xyz
h[:a][:b][:c] #=> :xyz
h[:x][:y][:z] = :abc
h.x.y.z #=> :abc
```
|
| | |
|
| |
|
|
|
|
|
|
| |
When running rspec specs on the ruby-grape project with warnings enabled
this warning is printed hundreds of times.
This change fixes the warning.
Also, turn on warnings when running rspec to see when this happens.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we switched to using `#respond_to?` to detecting whether to log
a Mash collision, we started reporting when we were overwriting keys
that already exist in the Mash. This is a poor experience because it
causes extra warnings (as in #414) or, in the worst case, causes an
"undefined method" error (as in #413).
This change fixes that problem and benchmarks to ensure we're not
appreciably regressing performance. The results of two benchmarks are
below:
```
bundle exec ruby benchmark/mash_method_access.rb:
Warming up --------------------------------------
before 92.456k i/100ms
Calculating -------------------------------------
before 1.290M (± 4.4%) i/s - 6.472M in 5.028183s
Pausing here -- run Ruby again to measure the next benchmark...
Warming up --------------------------------------
after 92.941k i/100ms
Calculating -------------------------------------
after 1.326M (± 5.4%) i/s - 6.692M in 5.060756s
Comparison:
after: 1326239.2 i/s
before: 1289624.0 i/s - same-ish: difference falls within error
```
and
```
within spec/integrations/omniauth,
bundle exec rake perf:ips
Warming up --------------------------------------
before 1.260k i/100ms
Calculating -------------------------------------
before 13.114k (± 4.2%) i/s - 66.780k in 5.101689s
Pausing here -- run Ruby again to measure the next benchmark...
Warming up --------------------------------------
after 1.299k i/100ms
Calculating -------------------------------------
after 13.149k (± 4.0%) i/s - 66.249k in 5.046630s
Comparison:
after: 13148.9 i/s
before: 13113.8 i/s - same-ish: difference falls within error
```
Closes #413
Closes #414
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the behaviors of Mash that we see regularly surprise users is
that Mash stringifies any keys passed into it. This leads to unexpected
lack of synergy between Mash and its cousins (particularly Dash), since
the property DSLs do not handle indifferent key access.
This extension ensures that the original keys are kept inside the Mash's
data structure, at the expense of more costly logic for fetching
information indifferently. I have included a benchmark that compares the
two. The benchmark shows that when you are passing string keys into a
Mash, using this extension will actually be _faster_ than the default
implementation, but that the reverse is true when passing symbol keys.
In #296, I tried to do this universally for all Mashes, which slowed
down the fetching behavior for Mash significantly. I like this attempt
much better because it allows users to opt into the new behavior if they
want it, while still keeping the default implementation as-is.
Fixes #196 by giving the option of keeping the original structure of the
Mash when using it with Dash.
Fixes #246 by giving the option of opting into keeping the original
keys.
Closes #296 by giving a more flexible path forward that doesn't change
the semantics of the main Mash class.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We often have requests to make Mash symbolize keys by default. Since
Hashie is used across so many different version of Ruby, we have been
hesitant to make this behavior the default. However, there are valid use
cases for wanting symbol keys.
To satisfy both the needs of those on older Rubies and the needs of
those who want symbol keys, this extension gives the end-user the
ability to toggle on symbolized keys in their Mash subclasses. By adding
this ability, we can wait to implement the symbol keys as a default for
a while longer.
See #341, #342 for more information. This is a half-measure toward the
implementation of #342 (which makes Mash symbolize keys by default).
|
| |
|
|
|
|
|
|
| |
In some circumstances when a project has the Rails constant defined we
may still not be able to require the rails/railtie dependency. Before this
change this would raise an exception. This change seeks to add better
detection of the railtie dependency and add logging that this dependency
is missing but still allow execution to continue.
|
| |
|
|
|
|
|
|
| |
This standardizes the way we're loading the example applications for the
integration tests so we're actually testing the behavior of the
application in each case. They're also structured in such a way to test
that the Hashie logger doesn't accidentally write to the STDOUT during
the initialization process of the applications.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
With a test that would fail without this patch.
|
| |\
| |
| | |
Allow Mash subclasses to disable warnings
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since we are transitively used as a dependency in many projects, we
should have given the ability to toggle this behavior off. The logging
feature is more of a "help people get started with Mash" feature. If
you're using Hashie in a library, it's likely that you already know the
tradeoffs of attempting to override methods on the object.
To use this feature, you only have to subclass Mash and then call the
class method:
```ruby
class KeyStore < Hashie::Mash
disable_warnings
end
```
|
| |\ \
| |/
|/| |
Bring integration tests into main test harness
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have a nice integration spec harness, so let's make sure we use it
when we're working on the gem. I'm making the following changes:
* Make `bundle exec rake` run integration specs, except on Travis.
* Silence a warning in the OmniAuth integration spec that has nothing to
do with Hashie.
* Make Guard run integration specs when appropriate. Now, when you run
all tasks you will run integration specs. Also, if you modify an
integration spec, it will run. Lastly, if you modify anything in `lib`
the integration specs will run.
* Keeps the extra Travis build that only runs integration specs. Travis
didn't like the Rake task that included it and there's extra signal by
doing it this way anyway.
|
| |/
|
|
| |
Correct usage of a shared_context is to use include_context
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
CodeClimate > 1.0 uses SimpleCov and requires the test reporter to be
called explicitly:
https://github.com/codeclimate/ruby-test-reporter/blob/master/CHANGELOG.
md#v100-2016-11-03
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
IgnoreUndeclared
|
| |
|
|
| |
https://github.com/intridea/hashie/issues/331
|
| | |
|
| |\
| |
| | |
Stringified translations wasn't working in IgnoreUndeclared.
|
| | |
| |
| |
| |
| |
| | |
Translation from `:symbol` and translation from `'string'` are
different translations. No need in coercion to symbol or some other
coercions.
|
| |/ |
|
| |
|
|
|
|
|
|
|
| |
`HashWithDifferentAccess` wasn't properly setting the indifferent
access when merging in other hashes. This reruns `#convert!` after
calling the superclass implementation of the method, so it preserves
indifferent access on the resulting object.
Fixes #345
|
| | |
|
| |
|
|
|
|
|
|
| |
Added inheritance
Added multiple bang notation merging
Minor performace improvements - ends_with? is faster than regexp
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`Hashie::Extensions::DeepLocate.deep_locate`, when passed a key, did not
take into account indifferent access. This lead to a regression in
v3.4.1 when `Hashie::Extensions::DeepFind` was modified to be backed by
`DeepLocate`.
This change makes the default comparator aware of indifferent access by
inspecting the object that it is called on. It works with both
`ActiveSupport::HashWithIndifferentAccess` and
`Hashie::Extensions::IndifferentAccess`.
Fixes #309
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation about the MethodQuery module spells out the expected
behavior. While the spec suite appeared to be testing the same, the
RSpec matchers were not actually checking the behavior properly. This
lead to a divergence between the expected behavior, as outlined in the
module documentation, and the actual behavior, as tested in the spec
suite.
This is the reason that #299 is happening: the expected behavior is not
the actual behavior. I have included a test for #299 to show that it
works as expected in this branch.
This change makes the spec suite match the behavior in the module
documentation, then modifies the methods to match the documentated
specification.
Lastly, I took the time to clean up the MethodQuery module for two
reasons:
1. The old implementation used Regexps on the stringified
method names, which is unnecessary since we have the wonderful
`String#end_with?` method to check the suffix of a strings.
2. The old logic was difficult to reason through, so I clarified the
intent of the methods by reducing the complexity of the conditionals
and extracting meaningful methods where possible.
|
| |
|
|
|
|
|
| |
Extension
- Updated, and enhanced specs
- Improved documentation
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
accessed that does not exist in the hash.
In Python a "Hash" is called a "Dictionary", and ...
> "It is an error to extract a value using a non-existent key."
See: https://docs.python.org/2/tutorial/datastructures.html#dictionaries
EXAMPLE:
class StrictHash < Hash
include Hashie::Extensions::StrictKeyAccess
end
>> hash = StrictHash[foo: "bar"]
=> {:foo=>"bar"}
>> hash[:foo]
=> "bar"
>> hash[:cow]
KeyError: key not found: :cow
|
| |
|
|
|
| |
- a one liner with no complexity for pending specs by Ruby Engine / Version
- removes all complexity from Hashie
|
| |
|
|
| |
- Better paradigm for pending specs due to bugs in interpreter
|
