aboutsummaryrefslogtreecommitdiffstats
path: root/activemodel/lib/active_model/type
Commit message (Collapse)AuthorAgeFilesLines
* Ensure casting by decimal attribute when queryingRyuta Kamizono2018-11-121-0/+4
| | | | | | | | | | Related 34cc301f03aea2e579d6687a9ea9782afc1089a0. `QueryAttribute#value_for_database` calls only `type.serialize`, and `Decimal#serialize` is a no-op unlike other attribute types. Whether or not `serialize` will invoke `cast` is undefined in our test cases, but it actually does not work properly unless it does so for now.
* Add new exception message to datetime from hash castwilddima2018-10-211-3/+3
|
* Add `Style/RedundantFreeze` to remove redudant `.freeze`Yasuo Honda2018-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | Since Rails 6.0 will support Ruby 2.4.1 or higher `# frozen_string_literal: true` magic comment is enough to make string object frozen. This magic comment is enabled by `Style/FrozenStringLiteralComment` cop. * Exclude these files not to auto correct false positive `Regexp#freeze` - 'actionpack/lib/action_dispatch/journey/router/utils.rb' - 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb' It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333 Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed. * Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required - 'actionpack/test/controller/test_case_test.rb' - 'activemodel/test/cases/type/string_test.rb' - 'activesupport/lib/active_support/core_ext/string/strip.rb' - 'activesupport/test/core_ext/string_ext_test.rb' - 'railties/test/generators/actions_test.rb'
* Fix non_numeric_string?Yoshiyuki Kinjo2018-09-071-1/+1
| | | | | | | | | | | | | | | | For example, dirty checking was not right for the following case: ``` model.int_column = "+5" model.float_column = "0.5E+1" model.decimal_column = "0.5e-3" ``` It is enough to see whether leading character is a digit for avoiding invalid numeric expression like 'wibble' to be type-casted to 0, as this method's comment says. Fixes #33801
* Faster time_value.rbschneems2018-08-291-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The multiplication of the value takes a long time when we can instead mutate and use the string value directly. The `microsec` perf increases speed by 27% in the ideal case (which is the most common). ``` original_string = ".443959" require 'benchmark/ips' Benchmark.ips do |x| x.report("multiply") { string = original_string.dup (string.to_r * 1_000_000).to_i } x.report("new ") { string = original_string.dup if string && string.start_with?(".".freeze) && string.length == 7 string[0] = ''.freeze string.to_i end } x.compare! end # Warming up -------------------------------------- # multiply 125.783k i/100ms # new 146.543k i/100ms # Calculating ------------------------------------- # multiply 1.751M (± 3.3%) i/s - 8.805M in 5.033779s # new 2.225M (± 2.1%) i/s - 11.137M in 5.007110s # Comparison: # new : 2225289.7 i/s # multiply: 1751254.2 i/s - 1.27x slower ```
* Ensure casting by boolean attribute when queryingRyuta Kamizono2018-05-291-0/+4
| | | | | | | | | | | `QueryAttribute#value_for_database` calls only `type.serialize`, and `Boolean#serialize` is a no-op unlike other attribute types. It caused the issue #32624. Whether or not `serialize` will invoke `cast` is undefined in our test cases, but it actually does not work properly unless it does so for now. Fixes #32624.
* Make force equality checking more strictly not to allow serialized attributeRyuta Kamizono2018-05-251-0/+4
| | | | | | | | | | | Since #26074, introduced force equality checking to build a predicate consistently for both `find` and `create` (fixes #27313). But the assumption that only array/range attribute have subtype was wrong. We need to make force equality checking more strictly not to allow serialized attribute. Fixes #32761.
* Fix user_input_in_time_zone to coerce non valid string into nilAnnie-Claude Côté2018-05-161-0/+2
| | | | Before it was coercing an invalid string into "2000-01-01 00:00:00".
* Add missing require for string to timezone conversionAnnie-Claude Côté2018-05-161-0/+1
| | | | Inside user_input_in_time_zone we call in_time_zone on the value and value can be a String.
* Normalize date component when writing to time columnsAndrew White2018-03-111-5/+1
| | | | | | | | | | | | | | | For legacy reasons Rails stores time columns on sqlite as full timestamp strings. However because the date component wasn't being normalized this meant that when they were read back they were being prefixed with 2001-01-01 by ActiveModel::Type::Time. This had a twofold result - first it meant that the fast code path wasn't being used because the string was invalid and second it was corrupting the second fractional component being read by the Date._parse code path. Fix this by a combination of normalizing the timestamps on writing and also changing Active Model to be more lenient when detecting whether a string starts with a date component before creating the dummy time value for parsing.
* Apply time column precision on assignmentAndrew White2018-03-111-1/+1
| | | | | | | In #20317, datetime columns had their precision applied on assignment but that behaviour wasn't applied to time columns - this commit fixes that. Fixes #30301.
* Ruby 2.4: take advantage of String#unpack1Jeremy Daer2018-03-011-1/+1
| | | | | https://bugs.ruby-lang.org/issues/12752 https://ruby-doc.org/core-2.4.0/String.html#method-i-unpack1
* PostgreSQL: Allow BC dates like datetime consistentlyRyuta Kamizono2018-02-231-1/+1
| | | | | | | | | BC dates are supported by both date and datetime types. https://www.postgresql.org/docs/current/static/datatype-datetime.html Since #1097, new datetime allows year zero as 1 BC, but new date does not. It should be allowed even in new date consistently.
* Rails 6 requires Ruby 2.3+Jeremy Daer2018-02-172-16/+3
|
* [Active Model] require => require_relativeAkira Matsuda2017-10-213-6/+6
| | | | This basically reverts ee5cfc01a5797f854c8441539b0cae326a81b963
* [ci skip] Postgres --> PostgreSQLRyuta Kamizono2017-08-081-1/+1
|
* Allow multiparameter assigned attributes to be used with `text_field`Sean Griffin2017-07-172-0/+8
| | | | | | | | | | | | | | | | | | | | | Between 4.2 and 5.0 the behavior of how multiparameter attributes interact with `_before_type_cast` changed. In 4.2 it returns the post-type-cast value. After 5.0, it returns the hash that gets sent to the type. This behavior is correct, but will cause an issue if you then tried to render that value in an input like `text_field` or `hidden_field`. In this case, we want those fields to use the post-type-cast form, instead of the `_before_type_cast` (the main reason it uses `_before_type_cast` at all is to avoid losing data when casting a non-numeric string to integer). I've opted to modify `came_from_user?` rather than introduce a new method for this as I want to avoid complicating that contract further, and technically the multiparameter hash didn't come from assignment, it was constructed internally by AR. Close #27888.
* Use frozen string literal in activemodel/Kir Shatrov2017-07-1618-0/+36
|
* Fix `ActiveModel::Type::DateTime#serialize`Lisa Ugray2017-07-051-0/+4
| | | | | `ActiveModel::Type::DateTime#serialize` should return a `Time` object so that finding by a datetime column works correctly.
* [Active Model] require => require_relativeAkira Matsuda2017-07-013-6/+6
|
* Don't freeze input stringsMatthew Draper2017-04-121-1/+6
| | | | | | | | | See 34321e4a433bb7eef48fd743286601403f8f7d82 for background on ImmutableString vs String. Our String type cannot delegate typecasting to ImmutableString, because the latter freezes its input: duplicating the value after that gives us an unfrozen result, but still mutates the originally passed object.
* Merge pull request #25296 from kamipo/use_inspect_for_type_cast_for_schemaRafael França2017-02-282-2/+2
|\ | | | | Use `inspect` in `type_cast_for_schema` for date/time and decimal values
| * Use `inspect` in `type_cast_for_schema` for date/time and decimal valuesRyuta Kamizono2016-12-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently dumping defaults on schema is inconsistent. Before: ```ruby create_table "defaults", force: :cascade do |t| t.string "string_with_default", default: "Hello!" t.date "date_with_default", default: '2014-06-05' t.datetime "datetime_with_default", default: '2014-06-05 07:17:04' t.time "time_with_default", default: '2000-01-01 07:17:04' t.decimal "decimal_with_default", default: 1234567890 end ``` After: ```ruby create_table "defaults", force: :cascade do |t| t.string "string_with_default", default: "Hello!" t.date "date_with_default", default: "2014-06-05" t.datetime "datetime_with_default", default: "2014-06-05 07:17:04" t.time "time_with_default", default: "2000-01-01 07:17:04" t.decimal "decimal_with_default", default: "1234567890" end ```
* | Match the behavior of bigdecimal after ↵Rafael Mendonça França2017-02-241-1/+5
| | | | | | | | https://github.com/ruby/bigdecimal/pull/55
* | Fix invalid string Decimal casting under ruby 2.4John Hawthorn2017-02-241-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Ruby 2.4, BigDecimal(), as used by the Decimal cast, was changed so that it will raise ArgumentError when passed an invalid string, in order to be more consistent with Integer(), Float(), etc. The other numeric types use ex. to_i and to_f. Unfortunately, we can't simply change BigDecimal() to to_d. String#to_d raises errors like BigDecimal(), unlike all the other to_* methods (this should probably be filed as a ruby bug). Instead, this simulates the existing behaviour and the behaviour of the other to_* methods by finding a numeric string at the start of the passed in value, and parsing that using BigDecimal(). See also https://bugs.ruby-lang.org/issues/10286 https://github.com/ruby/bigdecimal/commit/3081a627cebdc1fc119425c7a9f009dbb6bec8e8
* | Indicate units of 'limit' in 'Integer' error message.Corey Farwell2017-02-151-1/+1
| |
* | Make BigDecimal casting consistent on different platformsKir Shatrov2017-01-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now it behaves differently on JRuby: ``` --- expected +++ actual @@ -1 +1 @@ -#<BigDecimal:5f3c866c,'0.333333333333333333',18(20)> +#<BigDecimal:16e0afab,'0.3333333333333333',16(20)> ``` My initial PR (https://github.com/rails/rails/pull/27324) offered to let the precision to be decided by the platform and change the test expection, but other contributors suggested that we should change the default precision in Rails to be consistent of all platforms. The value (18) comes from the max default precision that comes from casting Rational(1/3) to BigDecimal.
* | Revert "Merge pull request #27528 from kamipo/extract_casted_booleans"Kasper Timm Hansen2017-01-011-12/+4
| | | | | | | | | | | | | | | | | | | | | | As pointed out by @matthewd this change makes ImmutableString aware of MysqlString's existence whereas previously MysqlString was only overriding public API. cc @kamipo This reverts commit e632c2fa4cb60072a778ce95c952a0fa95e5b074, reversing changes made to 334a7dcf107cd3ff1697163d331d289d6d65dcd7.
* | Extract `casted_true`/`casted_false` for `Type::ImmutableString`Ryuta Kamizono2017-01-011-4/+12
| | | | | | | | | | | | The only difference between `Type::ImmutableString` and its subclasses is the representation of the casted booleans. Prefer extracting `casted_true`/`casted_false` and override these by subclasses.
* | Describe what we are protectingAkira Matsuda2016-12-232-0/+6
| |
* | Change ActiveModel::Type::Helpers to :nodoc: [ci skip]MSP-Greg2016-12-164-8/+8
|/
* Merge pull request #26696 from iainbeeston/only-ruby-types-in-activemodelSean Griffin2016-12-083-37/+0
|\ | | | | | | Moved database-specific ActiveModel types into ActiveRecord
| * Moved database-specific ActiveModel types into ActiveRecordIain Beeston2016-10-143-37/+0
| | | | | | | | ie. DecimalWithoutScale, Text and UnsignedInteger
* | Fix `apply_seconds_precision` not to be affected by `mathn`Ryuta Kamizono2016-11-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently `apply_seconds_precision` cannnot round usec when after `require 'mathn'`. ``` irb(main):001:0> 1234 / 1000 * 1000 => 1000 irb(main):002:0> 1234 - 1234 % 1000 => 1000 irb(main):003:0> require 'mathn' => true irb(main):004:0> 1234 / 1000 * 1000 => 1234 irb(main):005:0> 1234 - 1234 % 1000 => 1000 ```
* | Add more rubocop rules about whitespacesRafael Mendonça França2016-10-291-1/+1
|/
* Merge pull request #24571 from raimo/patch-1Sean Griffin2016-10-041-0/+9
|\ | | | | Print the proper ::Float::INFINITY value when used as a default value
| * Print the proper ::Float::INFINITY value when used as a default valueRaimo Tuisku2016-05-231-0/+9
| | | | | | | | Addresses https://github.com/rails/rails/issues/22396
* | Fix broken comments indentation caused by rubocop auto-correct [ci skip]Ryuta Kamizono2016-09-143-6/+6
| | | | | | | | | | | | All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772. But comments was still kept absolute position. This commit aligns comments with method definitions for consistency.
* | Fix Remaining Case-In-Assignment Statement FormattingAlex Kitchens2016-09-061-12/+13
| | | | | | | | | | | | | | | | | | Recently, the Rails team made an effort to keep the source code consistent, using Ruboco (bb1ecdcc677bf6e68e0252505509c089619b5b90 and below). Some of the case statements were missed. This changes the case statements' formatting and is consistent with changes in 810dff7c9fa9b2a38eb1560ce0378d760529ee6b and db63406cb007ab3756d2a96d2e0b5d4e777f8231.
* | apply case-in-assignment patternXavier Noria2016-09-022-11/+13
| |
* | RuboCop is 100% green :tada:Xavier Noria2016-09-022-2/+2
| |
* | code gardening: removes redundant selfsXavier Noria2016-08-081-1/+1
| | | | | | | | | | | | | | | | | | A few have been left for aesthetic reasons, but have made a pass and removed most of them. Note that if the method `foo` returns an array, `foo << 1` is a regular push, nothing to do with assignments, so no self required.
* | applies remaining conventions across the projectXavier Noria2016-08-061-9/+9
| |
* | normalizes indentation and whitespace across the projectXavier Noria2016-08-0615-182/+182
| |
* | applies new string literal convention in activemodel/libXavier Noria2016-08-068-12/+12
| | | | | | | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* | systematic revision of =~ usage in AMoXavier Noria2016-07-241-1/+1
| |
* | [ci skip] add class level documentation to ActiveModel::Type::BooleanDavid Elliott2016-07-111-2/+13
| | | | | | | | add documentation of the behaviors of type coercion at the class level
* | Fix `Type::Date#serialize` to return a date object correctlyRyuta Kamizono2016-06-161-0/+4
| | | | | | | | | | | | | | | | Currently `Type::Date#serialize` does not cast a value to a date object. It should be cast to a date object for finding by date column correctly working. Fixes #25354.
* | Change RangeError to a more specific ActiveModel::RangeErrorChristian Blais2016-05-031-1/+1
|/ | | | | | The should make it easier for apps to rescue ActiveModel specific errors without the need to wrap all method calls with a generic rescue RangeError.
* Apply scale before precision when coercing floats to decimalSean Griffin2016-03-241-2/+10
| | | | | | | | | | | | | | | | Since precision is always larger than scale, it can actually change rounding behavior. Given a precision of 5 and a scale of 3, when you apply the precision of 5 to `1.25047`, the result is `1.2505`, which when the scale is applied would be `1.251` instead of the expected `1.250`. This issue appears to only occur with floats, as scale doesn't apply to other numeric types, and the bigdecimal constructor actually ignores precision entirely when working with strings. There's no way we could handle this for the "unknown object which responds to `to_d`" case, as we can't assume an interface for applying the scale. Fixes #24235