rails.git - Mirror of official rails repo with custom fixes.

	Commit message (Collapse)	Author	Age	Files	Lines
*	Use frozen-string-literal in ActiveRecord	Kir Shatrov	2017-07-19	1	-0/+2
\|
*	Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"	Matthew Draper	2017-07-02	1	-1/+0
\| \| \| \| \|	This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
*	Enforce frozen string in Rubocop	Kir Shatrov	2017-07-01	1	-0/+1
\|
*	Consolidate database specific JSON types to `Type::Json`	Ryuta Kamizono	2017-05-30	1	-37/+0
\|
*	Deserialize a raw value from the database in `changed_in_place?` for ↵	Ryuta Kamizono	2017-05-30	1	-0/+4
\| \| \| \| \| \| \| \|	`AbstractJson` Structured type values sometimes caused representation problems (keys sort order, spaces, etc). A raw value from the database should be deserialized (normalized) to prevent the problems.
*	Revert "Made ActiveRecord consistently use ActiveRecord::Type (not"	Sean Griffin	2016-10-23	1	-2/+2
\| \| \| \| \| \|	This reverts commit 671eb742eec77b5c8281ac2a2e3976ef32a6e424. This is not a change we would like moving forward.
*	Made ActiveRecord consistently use ActiveRecord::Type (not	Iain Beeston	2016-10-03	1	-2/+2
\| \| \| \| \| \| \| \|	ActiveModel::Type) Some code was previously referring to ActiveModel::Type::*. This could cause issues in the future if any of the ActiveRecord::Type classes were overridden in the future.
*	Serialize JSON attribute value nil as SQL NULL, not JSON 'null'	Trung Duc Tran	2016-09-23	1	-1/+5
\| \| \| \| \| \|	Test: JSON attribute value nil can be used in where(attr: nil) Add changelog entry
*	Properly serialize all JSON primitives in the AR JSON type	Sean Griffin	2016-04-13	1	-5/+1
\| \| \| \| \| \| \| \| \| \| \| \| \| \|	Previously we were assuming that the only valid types for encoding were arrays and hashes. However, any JSON primitive is an accepted value by both PG and MySQL. This does involve a minor breaking change in the handling of `default` in the schema dumper. This is easily worked around, as passing a hash/array literal would have worked fine in previous versions of Rails. However, because of this, I will not be backporting this to 4.2 or earlier. Fixes #24234
*	Various stylistic nitpicks	Sean Griffin	2015-09-21	1	-1/+1
\| \| \| \| \| \| \|	We do not need to require each file from AM individually, the type module does that for us. Even if the classes are extremely small right now, I'd rather keep any custom classes needed by AR in their own files, as they can easily have more complex changes in the future.
*	Move ActiveRecord::Type to ActiveModel	Kir Shatrov	2015-09-21	2	-2/+17
\| \| \| \|	The first step of bringing typecasting to ActiveModel
*	JSON is still an adapter specific type.	Sean Griffin	2015-08-21	1	-0/+33
	Several changes were made in #21110 which I am strongly opposed to. (this is what I get for going on vacation. :trollface:) No type should be introduced into the generic `ActiveRecord::Type` namespace, and certainly should not be registered into the registry unconstrained unless it is supported by all adapters (which basically means that it was specified in the ANSI SQL standard). I do not think `# :nodoc:` ing the type is sufficient, as it still makes the code of Rails itself very unclear as to what the role of that class is. While I would argue that this shouldn't even be a super class, and that MySql and PG's JSON types are only superficially duplicated (they might look the same but will change for different reasons in the future). However, I don't feel strongly enough about it as a point of contention (and the biggest cost of harming the blameability has already occured), so I simply moved the superclass into a namespace where its role is absolutely clear. After this change, `attribute :foo, :json` will once again work with MySQL and PG, but not with Sqlite3 or any third party adapters. Unresolved questions -------------------- The types that and adapter publishes (at least those are unique to that adapter, and not adding additional behavior like `MysqlString` should probably be part of the adapter's public API. Should we standardize the namespace for these, and document them?