aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/type
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Made ActiveRecord consistently use ActiveRecord::Type (not"Sean Griffin2016-10-234-14/+4
| | | | | | This reverts commit 671eb742eec77b5c8281ac2a2e3976ef32a6e424. This is not a change we would like moving forward.
* Made ActiveRecord consistently use ActiveRecord::Type (notIain Beeston2016-10-034-4/+14
| | | | | | | | 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 Tran2016-09-231-1/+5
| | | | | | Test: JSON attribute value nil can be used in where(attr: nil) Add changelog entry
* Add `Type.default_value` and use it everywhere for internalRyuta Kamizono2016-08-261-5/+1
| | | | For reduce instantiating `Type::Value`.
* normalizes indentation and whitespace across the projectXavier Noria2016-08-065-64/+63
|
* applies new string literal convention in activerecord/libXavier Noria2016-08-062-2/+2
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Fix false positive mutation detection when JSON is used with serializeSean Griffin2016-05-121-1/+7
| | | | | | | | | | | | | When looking for mutation, we compare the serialized version of the value to the before_type_cast form. `Type::Serialized` was breaking this contract by passing the already serialized attribute to the subtype's mutation detection. This never manifested previously, as all mutable subtypes either didn't do anything in their `serialize` method, or had a way to detect double serialization (e.g. `is_a?(String)`). However, now that JSON types can handle string primitives, we need to avoid double serialization. Fixes #24993.
* Add `quoted_time` for truncating the date part of a time column valueRyuta Kamizono2016-04-141-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Context #24522. TIME column on MariaDB doesn't ignore the date part of the string when it coerces to time. ``` root@localhost [test] > CREATE TABLE `foos` (`id` int AUTO_INCREMENT PRIMARY KEY, `start` time(0), `finish` time(4)) ENGINE=InnoDB; Query OK, 0 rows affected (0.02 sec) root@localhost [test] > INSERT INTO `foos` (`start`, `finish`) VALUES ('2000-01-01 12:30:00', '2000-01-01 12:30:00.999900'); Query OK, 1 row affected, 2 warnings (0.00 sec) Note (Code 1265): Data truncated for column 'start' at row 1 Note (Code 1265): Data truncated for column 'finish' at row 1 root@localhost [test] > SELECT `foos`.* FROM `foos`; +----+----------+---------------+ | id | start | finish | +----+----------+---------------+ | 1 | 12:30:00 | 12:30:00.9999 | +----+----------+---------------+ 1 row in set (0.00 sec) root@localhost [test] > SELECT `foos`.* FROM `foos` WHERE `foos`.`start` = '2000-01-01 12:30:00' LIMIT 1; Empty set (0.00 sec) root@localhost [test] > SELECT `foos`.* FROM `foos` WHERE `foos`.`start` = '12:30:00' LIMIT 1; +----+----------+---------------+ | id | start | finish | +----+----------+---------------+ | 1 | 12:30:00 | 12:30:00.9999 | +----+----------+---------------+ 1 row in set (0.00 sec) ```
* Properly serialize all JSON primitives in the AR JSON typeSean Griffin2016-04-131-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
* Require only necessary concurrent-ruby classes.Jerry D'Antonio2015-11-041-1/+1
|
* Clean up the implementation of AR::DirtySean Griffin2015-09-241-0/+6
| | | | | | | | | | | | | This moves a bit more of the logic required for dirty checking into the attribute objects. I had hoped to remove the `with_value_from_database` stuff, but unfortunately just calling `dup` on the attribute objects isn't enough, since the values might contain deeply nested data structures. I think this can be cleaned up further. This makes most dirty checking become lazy, and reduces the number of object allocations and amount of CPU time when assigning a value. This opens the door (but doesn't quite finish) to improving the performance of writes to a place comparable to 4.1
* Simplify the implementation of Active Model's type registrySean Griffin2015-09-211-6/+11
| | | | | | | | | | | | | | | Things like decorations, overrides, and priorities only matter for Active Record, so the Active Model registry can be implemented much more simply. At this point, I wonder if having Active Record's registry inherit from Active Model's is even worth the trouble? The Active Model class was also missing test cases, which have been backfilled. This removes the error when two types are registered with the same name, but given that Active Model is meant to be significantly more generic, I do not think this is an issue for now. If we want, we can raise an error at the point that someone tries to register it.
* Various stylistic nitpicksSean Griffin2015-09-215-2/+24
| | | | | | | 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.
* `TypeMap` and `HashLookupTypeMap` shouldn't be in Active ModelSean Griffin2015-09-212-0/+87
| | | | | | These are used by the connection adapters to convert SQL type information into the appropriate type object, and makes no sense outside of the context of Active Record
* Move ActiveRecord::Type to ActiveModelKir Shatrov2015-09-2125-798/+30
| | | | The first step of bringing typecasting to ActiveModel
* Replaced `ThreadSafe::Map` with successor `Concurrent::Map`.Jerry D'Antonio2015-09-191-3/+3
| | | | | | | The thread_safe gem is being deprecated and all its code has been merged into the concurrent-ruby gem. The new class, Concurrent::Map, is exactly the same as its predecessor except for fixes to two bugs discovered during the merge.
* Respect scale of the column in the Decimal typeRafael Mendonça França2015-09-011-1/+3
| | | | [Rafael Mendonça França + Jean Boussier]
* JSON is still an adapter specific type.Sean Griffin2015-08-212-31/+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?
* Add a native JSON data type support in MySQLRyuta Kamizono2015-08-181-0/+31
| | | | | | | | | | 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
* Display decimal defaults as strings to keep precisionJohn Gesimondo2015-06-231-1/+1
|
* Refactoring `ActiveRecord::Type::Integer` limityui-knk2015-05-181-3/+6
|
* Reduce memory usage when loading types in PGSean Griffin2015-03-291-2/+8
| | | | | | | | | | | | | We were never clearing the `PG::Result` object used to query the types when the connection is first established. This would lead to a potentially large amount of memory being retained for the life of the connection. Investigating this issue also revealed several low hanging fruit on the performance of these methods, and the number of allocations has been reduced by ~90%. Fixes #19578
* Provide a more truthful #inspectMatthew Draper2015-03-231-0/+4
| | | | | | This is obviously all very internal, but sometimes you have to look at it... and when you do, it'll save a lot of confusion if it doesn't lie about its identity.
* Make sure to persist a newly-nil serialized valueMatthew Draper2015-03-231-1/+3
| | | | | | | The subtype will (quite reasonably) ignore the possibility that it has `changed_in_place?` by becoming nil. Fixes #19467
* Some documentation edits [ci skip]Robin Dupret2015-03-051-3/+3
| | | | | | * Fix a few typos * Wrap some lines around 80 chars * Rephrase some statements
* Format the time string according to the precision of the time columnRyuta Kamizono2015-02-202-18/+18
| | | | It is also necessary to format a time column like a datetime column.
* Rm `Type#type_cast`Sean Griffin2015-02-175-18/+10
| | | | | | | | | 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_from_user` -> `cast`Sean Griffin2015-02-173-4/+4
|
* `type_cast_for_database` -> `serialize`Sean Griffin2015-02-178-11/+11
|
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-175-8/+8
|
* Register adapter specific types with the global type registrySean Griffin2015-02-151-1/+4
| | | | | | We do this in the adapter classes specifically, so the types aren't registered if we don't use that adapter. Constants under the PostgreSQL namespace for example are never loaded if we're using mysql.
* Add a global type registry, used to lookup and register typesSean Griffin2015-02-151-0/+139
| | | | | | | | As per previous discussions, we want to give users the ability to reference their own types with symbols, instead of having to pass the object manually. This adds the class that will be used to do so. ActiveRecord::Type.register(:money, MyMoneyType)
* Remove most PG specific type subclassesSean Griffin2015-02-111-1/+7
| | | | | | | | | The latest version of the PG gem can actually convert the primitives for us in C code, which gives a pretty substantial speed up. A few cases were only there to add the `infinity` method, which I just put on the range type (which is the only place it was used). Floats also needed to parse `Infinity` and `NaN`, but it felt reasonable enough to put that on the generic form.
* Refactor microsecond precision to be database agnosticSean Griffin2015-02-101-14/+11
| | | | | | | | | | The various databases don't actually need significantly different handling for this behavior, and they can achieve it without knowing about the type of the object. The old implementation was returning a string, which will cause problems such as breaking TZ aware attributes, and making it impossible for the adapters to supply their logic for time objects.
* Fix rounding problem for PostgreSQL timestamp columnRyuta Kamizono2015-02-081-7/+14
| | | | | If timestamp column have the precision, it need to format according to the precision of timestamp column.
* rm `Type#number?`Sean Griffin2015-02-072-8/+0
| | | | | This predicate is only used in `query_attribute`, and is relatively easy to remove without adding a bunch of is a checks.
* rm `Type#text?`Sean Griffin2015-02-072-8/+0
| | | | | | | | | | | | | | | | This predicate was only to figure out if it's safe to do case insensitive comparison, which is only a problem on PG. Turns out, PG can just tell us whether we are able to do it or not. If the query turns out to be a problem, let's just replace that method with checking the SQL type for `text` or `character`. I'd rather not burden the type objects with adapter specific knowledge. The *real* solution, is to deprecate this behavior entirely. The only reason we need it is because the `:case_sensitive` option for `validates_uniqueness_of` is documented as "this option is ignored for non-strings". It makes no sense for us to do that. If the type can't be compared in a case insensitive way, the user shouldn't tell us to do case insensitive comparison.
* Move non-type objects into the `Type::Helpers` namespaceSean Griffin2015-02-0714-97/+106
| | | | | | | 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.
* rm `ActiveRecord::Type::Decorator`Sean Griffin2015-02-072-25/+0
| | | | | | | It only existed to make sure the subclasses of `Delegator` were YAML serializable. As of Ruby 2.2, these are YAML dumpable by default, as it includes https://github.com/tenderlove/psych/commit/2a4d9568f7d5d19c00231cf48eb855cc45ec3394
* Push multi-parameter assignement into the typesSean Griffin2015-02-077-11/+52
| | | | | | | | | | | | This allows us to remove `Type::Value#klass`, as it was only used for multi-parameter assignment to reach into the types internals. The relevant type objects now accept a hash in addition to their previous accepted arguments to `type_cast_from_user`. This required minor modifications to the tests, since previously they were relying on the fact that mulit-parameter assignement was reaching into the internals of time zone aware attributes. In reaility, changing those properties at runtime wouldn't change the accessor methods for all other forms of assignment.
* Grammar and RDoc formattingSean Griffin2015-02-061-14/+14
|
* Docs pass for the attributes APISean Griffin2015-02-061-23/+42
|
* Move integer range validation to never raise on assignmentSean Griffin2015-01-231-5/+9
| | | | | | | | | | | | | | | | | Given that this was originally added to normalize an error that would have otherwise come from the database (inconsistently), it's more natural for us to raise in `type_cast_for_database`, rather than `type_cast_from_user`. This way, things like numericality validators can handle it instead if the user chooses to do so. It also fixes an issue where assigning an out of range value would make it impossible to assign a new value later. This fixes several vague issues, none of which were ever directly reported, so I have no issue number to give. Places it was mentioned which I can remember: - https://github.com/thoughtbot/shoulda-matchers/blob/9ba21381d7caf045053a81f32df7de2f49687820/lib/shoulda/matchers/active_model/allow_value_matcher.rb#L261-L263 - https://github.com/rails/rails/issues/18653#issuecomment-71197026
* Merge pull request #18543 from henrik/integer_limit_or_defaultYves Senn2015-01-151-2/+6
|\ | | | | Tiny: DRY default limit in ActiveRecord::Type::Integer
| * DRY default limit in ActiveRecord::Type::IntegerHenrik Nyh2015-01-151-2/+6
| |
* | Remove incorrect comment in ActiveRecord::Type::ValueHenrik Nyh2015-01-151-2/+1
|/ | | | | | | Says it's only used for the schema, but they are in fact used for other things. Integer verifies against the limit during casting, and Decimal uses precision during casting. It may be true that scale is only used for the schema.
* Time columns should support time zone aware attributesSean Griffin2015-01-152-0/+17
| | | | | | The types that are affected by `time_zone_aware_attributes` (which is on by default) have been made configurable, in case this is a breaking change for existing applications.
* Simplify boolean casting logicCarlos Antonio da Silva2015-01-041-3/+1
|
* Change the behavior of boolean columns to be closer to Ruby's semantics.Rafael Mendonça França2015-01-041-12/+3
| | | | | | | | Before this change we had a small set of "truthy", and all others are "falsy". Now, we have a small set of "falsy" values and all others are "truthy" matching Ruby's semantics.
* Support datetime values in AR::Type::DateTime#type_cast_for_databasebrainopia2015-01-031-1/+5
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 23:32:32 +0000