aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql/oid/json.rb
Commit message (Collapse)AuthorAgeFilesLines
* JSON is still an adapter specific type.Sean Griffin2015-08-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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?
* Add a native JSON data type support in MySQLRyuta Kamizono2015-08-181-35/+0
| | | | | | | | | | As of MySQL 5.7.8, MySQL supports a native JSON data type. Example: create_table :json_data_type do |t| t.json :settings end
* Rm `Type#type_cast`Sean Griffin2015-02-171-2/+2
| | | | | | | | | This helper no longer makes sense as a separate method. Instead I'll just have `deserialize` call `cast` by default. This led to a random infinite loop in the `JSON` pg type, when it called `super` from `deserialize`. Not really a great way to fix that other than not calling super, or continuing to have the separate method, which makes the public API differ from what we say it is.
* `type_cast_for_database` -> `serialize`Sean Griffin2015-02-171-1/+1
|
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-171-1/+1
|
* Move non-type objects into the `Type::Helpers` namespaceSean Griffin2015-02-071-1/+1
| | | | | | | The type code is actually quite accessible, and I'm planning to encourage people to look at the files in the `type` folder to learn more about how it works. This will help reduce the noise from code that is less about type casting, and more about random AR nonsense.
* Don't error when invalid json is assigned to a JSON columnSean Griffin2015-01-211-1/+1
| | | | | | | Keeping with our behavior elsewhere in the system, invalid input is assumed to be `nil`. Fixes #18629.
* Use the type object for sending JSON to the databaseSean Griffin2014-06-291-2/+10
|
* add missing `:nodoc:` for recent refactorings. [ci skip]Yves Senn2014-06-241-1/+1
| | | | | | | | | | Adding `# :nodoc:` to the parent `class` / `module` is not going to ignore nested classes or modules. There is a modifier `# :nodoc: all` but sadly the containing class or module will continue to be in the docs. /cc @sgrif
* Detect in-place changes on mutable AR attributesSean Griffin2014-06-131-4/+2
| | | | | | We have several mutable types on Active Record now. (Serialized, JSON, HStore). We need to be able to detect if these have been modified in place.
* Rename `type_cast` to `type_cast_from_database`Sean Griffin2014-06-091-5/+5
| | | | | | | | In some cases there is a difference between the two, we should always be doing one or the other. For convenience, `type_cast` is still a private method on type, so new types that do not need different behavior don't need to implement two methods, but it has been moved to private so it cannot be used accidentally.
* Make `_before_type_cast` actually be before type castSean Griffin2014-06-091-1/+5
| | | | | | | | | | | | | - The following is now true for all types, all the time - `model.attribute_before_type_cast == given_value` - `model.attribute == model.save_and_reload.attribute` - `model.attribute == model.dup.attribute` - `model.attribute == YAML.load(YAML.dump(model)).attribute` - Removes the remaining types implementing `type_cast_for_write` - Simplifies the implementation of time zone aware attributes - Brings tz aware attributes closer to being implemented as an attribute decorator - Adds additional point of control for custom types
* Bring type casting behavior of hstore/json in line with serializedSean Griffin2014-06-041-6/+0
| | | | | `@raw_attributes` should not contain the type-cast, mutable version of the value.
* pg, keep `hstore` and `json` attributes as `Hash` in @attributes.Yves Senn2014-05-281-1/+7
| | | | | | | | | | | The solution presented in this patch is not efficient. We should replace it in the near future. The following needs to be worked out: * Is `@attributes` storing the Ruby or SQL representation? * `cacheable_column?` is broken but `hstore` and `json` rely on that behavior Refs #15369. /cc @sgrif @rafaelfranca
* Move PG OID types to their own filesSean Griffin2014-05-211-0/+25
As we promote these classes to first class concepts, these classes are starting to gain enough behavior to warrant being moved into their own files. Many of them will become quite large as we move additional behavior to the type objects.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-16 09:47:10 +0000