Previously, calling `::JSON.{generate,dump}` sometimes causes
unexpected failures such as intridea/multi_json#86.
`::JSON.{generate,dump}` now bypasses the ActiveSupport JSON encoder
completely and yields the same result with or without ActiveSupport.
This means that it will **not** call `as_json` and will ignore any
options that the JSON gem does not natively understand. To invoke
ActiveSupport's JSON encoder instead, use `obj.to_json(options)` or
`ActiveSupport::JSON.encode(obj, options)`.
See [1] for why this is not a good idea.
As part of this refactor, circular reference protection in as_json has
been removed and the corresponding error class has been deprecated.
As discussed with @jeremy, circular reference error is considered
programmer errors and protecting against it is out of scope for
the encoder.
This is again based on the excellent work by @sergiocampama in #11728.
[1]: https://github.com/intridea/multi_json/pull/138#issuecomment-24468223
So strings can be humanized without being capitalized:
'employee_salary'.humanize # => "Employee salary"
'employee_salary'.humanize(capitalize: false) # => "employee salary"
JSON.{dump,generate} offered by the JSON gem is not compatiable with
Rails at the moment and can cause a lot of subtle bugs when passed
certain data structures. This changed all direct usage of the JSON gem
in internal Rails code to always go through AS::JSON.{decode,encode}.
We also shouldn't be implementing `to_json` most of the time, and
these occurances are replaced with an equivilent `as_json`
implementation to avoid problems down the road.
See [1] for all the juicy details.
[1]: intridea/multi_json#138 (comment)
These methods now takes the same options as Hash#as_json, for example:
struct = Struct.new(:foo, :bar).new
struct.foo = "hello"
struct.bar = "world"
json = struct.as_json(only: [:foo]) # => {foo: "hello"}
This is extracted from PR #11728 from @sergiocampama, see also the
discussion in #11460.
Rails 4.1 has switched away from MultiJson, and does not currently
support any options on `ActiveSupport::JSON.decode`. Passing in
unsupported options (i.e. any non-empty options hash) will now raise
an ArgumentError.
Rationale:
1. We cannot guarantee the underlying JSON parser won't change in the
future, hence we cannot guarantee a consistent set of options the
method could take
2. The `json` gem, which happens to be the current JSON parser, takes
many dangerous options that is irrelevant to the purpose of AS's
JSON decoding API
3. To reserve the options hash for future use, e.g. overriding default
global options like ActiveSupport.parse_json_times
This change *DOES NOT* introduce any changes in the public API. The
signature of the method is still decode(json_text, options). The
difference is this method previously accepted undocumented options
which does different things when the underlying adapter changes. It
now correctly raises an ArgumentError when it encounters options that
it does not recognize (and currently it does not support any options).
Before, you were required to attach *after* adding the methods to the
class, since the attachment process needed the methods to be present.
With this change, any new method will also be attached to the configured
namespace.
TL;DR The primary driver is to remove autoload surprise.
This is related to #12106. (The root cause for that ticket is that
json/add defines Regexp#to_json among others, but here I'll reproduce
the problem without json/add.)
Before:
>> require 'active_support/core_ext/to_json'
=> true
>> //.as_json
NoMethodError: undefined method `as_json' for //:Regexp
from (irb):3
from /Users/godfrey/.rvm/rubies/ruby-2.0.0-p195/bin/irb:16:in `<main>'
>> //.to_json
=> "\"(?-mix:)\""
>> //.as_json
=> "(?-mix:)"
After:
>> require 'active_support/core_ext/to_json'
=> true
>> //.as_json
=> "(?-mix:)"
This is because ActiveSupport::JSON is autoloaded the first time
Object#to_json is called, which causes additional core extentions
(previously defined in active_support/json/encoding.rb) to be loaded.
When someone require 'active_support/core_ext', the expectation is
that it would add certain methods to the core classes NOW. The
previous behaviour causes additional methods to be loaded the first
time you call `to_json`, which could cause nasty surprises and other
unplesant side-effects.
This change moves all core extensions in to core_ext/json. AS::JSON is
still autoloaded on first #to_json call, but since it nolonger
include the core extensions, it should address the aforementioned bug.
*Requiring core_ext/object/to_json now causes a deprecation warnning*
It turns out that ActionPack depends on the decoder to parse JSON
"fragments" (e.g. '"a string"', '1', 'null', etc), so we need to
enable quirks mode on JSON.parse. Also added coverage on the decoder
side to prevent regression.
Since we are dealing with untrusted user input, we should not be
using JSON.load. According to the docs[1]:
BEWARE: This method is meant to serialise data from trusted user
input, like from your own database server or clients under your
control, it could be dangerous to allow untrusted users to pass
JSON sources into it. The default options for the parser can be
changed via the ::load_default_options method.
[1] http://www.ruby-doc.org/stdlib-2.0/libdoc/json/rdoc/JSON.html#method-i-load
* eliminates need for temp Hash
Also added a couple of examples to DurationTest to specify:
* duration can be defined with units out of order e.g.
1.month + 1.year + 1.second + 1.day
* equality with a Fixnum works regardless of which operand is on which
side of the operator
Previously, an autoloaded constant `HTML::SomeClass` would not be marked
as autoloaded by AS::Dependencies. This is because the
`#loadable_constants_for_path` method uses `String#camelize` on the
inferred file path, which in turn means that, unless otherwise directed,
AS::Dependencies watches for loaded constants in the `Html` namespace.
By passing the original qualified constant name to `#load_or_require`,
this inference step is avoided, and the new constant is picked up in the
correct namespace.
This reverts commit 70d6e16fbad75b89dd1798ed697e7732b8606fa3, reversing
changes made to ea4db3bc078fb3093ecdddffdf4f2f4ff3e1e8f9.
Seems to be a code merge done by mistake.
This change is similar to #11736 & in same way switched with fixed string & the index of the hash for method name. the index was added because otherwise, ruby will raise Error.
We need to call `in_time_zone` to test that it isn't modifying the receiver
but since the variable isn't used it raises a warning so add an assertion
to make Ruby think it's being used.
When we call define_method with non-english chars like ¿por qué? it
errors out on JRuby as of 1.7.4 & would leave out the following error
invalid byte sequence in US-ASCII
To work around this issue, I have switched to define_test method call
define method with fixed string & the index of the hash. the index was
added because otherwise, ruby will raise method redefined warning.
As far as I can see there are no side-effect of this change for
other implementations. For readbility I have added a message to
asssert_equal informing for which word/phase the test has passed.
Before this Change:
JRuby:
Tests terminated suddenly with an error. no reported of Failues
or errors
MRI:
All Green.
After this Change,
JRuby:
the `ActiveSupport` TestsSuite gracefully fails with report at the end which test failed & why.
MRI:
All Green(no change)
Similar implementations of #in_time_zone exists for Date, Time and DateTime so
method is extracted into its own module. Also some logic is extracted into
private method.
