aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/type
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
|
* Correctly ignore `case_sensitive` for UUID uniqueness validationSean Griffin2014-12-262-0/+8
| | | | | | | | I think we should deprecate this behavior and just error if you tell us to do a case insensitive comparison for types which are not case sensitive. Partially reverts 35592307 Fixes #18195
* Don't treat `nil` as changed in serialized typesSean Griffin2014-12-231-1/+1
| | | | | | | We were ignoring the `default_value?` escape clause in the serialized type, which caused the default value to always be treated as changed. Fixes #18169
* docs, replace ` with + for proper rdoc output. [ci skip]Yves Senn2014-12-231-2/+2
|
* Fixing numeric attrs when set to same negative valueDaniel Fox2014-12-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug occurs when an attribute of an ActiveRecord model is an ActiveRecord::Type::Integer type or a ActiveRecord::Type::Decimal type (or any other type that includes the ActiveRecord::Type::Numeric module. When the value of the attribute is negative and is set to the same negative value, it is marked as changed. Take the following example of a Person model with the integer attribute age: class Person < ActiveRecord::Base # age :integer(4) end The following will produce the error: person = Person.new(age: -1) person.age = -1 person.changes => { "age" => [-1, -1] } person.age_changed? => true The problematic line is here: module ActiveRecord module Type module Numeric ... def non_numeric_string?(value) # 'wibble'.to_i will give zero, we want to make sure # that we aren't marking int zero to string zero as # changed. value.to_s !~ /\A\d+\.?\d*\z/ end end end end The regex match doesn't accept numbers with a leading '-'.
* Correctly handle Float -> BigDecimal with unspecified precisionSean Griffin2014-12-221-1/+9
| | | | Fixes #18122
* Fix undesirable RangeError by Type::Integer. Add Type::UnsignedInteger.Ryuta Kamizono2014-12-122-1/+20
|
* Fix out of range error messageRyuta Kamizono2014-11-251-1/+1
|
* Ensure the type map's cache is thread safeSean Griffin2014-11-241-3/+7
| | | | | Thanks to @thedarkone for pointing out that an instance of this object is used in a shared context.
* Reintroduce cache with testsSean Griffin2014-11-192-14/+24
|
* Add tests for `TypeMap#fetch` and push up to `TypeMap`Sean Griffin2014-11-192-5/+5
| | | | | | | It doesn't make sense for the subclass to implement this method, and not have it on the parent. We can also DRY up the implementation of `#lookup` to be defined in terms of fetch, which will give us a single point of entry
* Revert "PERF: optimise type lookup to avoid invoking procs"Sean Griffin2014-11-191-19/+1
| | | | This reverts commit da99a2a2982d35f670ad9647463e09bfe9032b70.
* Speed up integer casting from DBSean Griffin2014-11-181-0/+5
| | | | | | | | We don't have the check the range when the value is coming from the DB, so override type_cast_from_database to short-circuit the extra work. The difference is huge but the absolute gain is quite small. That being said this is a hotspot and it showed up on the radar when benchmarking discourse.
* Revert "[PERF] Speed up integer type casting from DB"Godfrey Chan2014-11-171-4/+1
| | | | | | This reverts commit 6f7910a and 52c70d4. Query params are type cased through the same method, so this approach doesn't work.
* :nail_care: Put escape clause first, keeps @sgrif happy :grin:Godfrey Chan2014-11-171-1/+2
| | | | See comment on 6f7910a
* [PERF] Speed up integer type casting from DBGodfrey Chan2014-11-171-1/+3
| | | | | | | | | | | | | | | | | | | We don't have the check the range when the value is coming from the DB, so override type_cast_from_database to short-circuit the extra work. type_cast_from_database (small) 3437507.5 (±29.2%) i/s - 14223135 in 4.996973s type_cast_from_database (large) 3158588.7 (±28.3%) i/s - 13265628 in 4.992121s type_cast (small) 481984.8 (±14.2%) i/s - 2352012 in 5.005694s type_cast (large) 477331.8 (±14.2%) i/s - 2332824 in 5.012365s Comparison: type_cast_from_database (small): 3437507.5 i/s type_cast_from_database (large): 3158588.7 i/s - 1.09x slower type_cast (small): 481984.8 i/s - 7.13x slower type_cast (large): 477331.8 i/s - 7.20x slower The difference is huge but the absolute gain is quite small. That being said this is a hotspot and it showed up on the radar when benchmarking discourse.
* PERF: optimise type lookup to avoid invoking procsSam2014-11-171-1/+19
|
* Use `DelegateClass` instead of `SimpleDelegator` for type decoratorsSean Griffin2014-11-141-1/+1
| | | | There is a significant performance difference between the two. Closes
* Revert the behavior of booleans in string columns to that of 4.1Sean Griffin2014-11-091-4/+4
| | | | | | | | | | | | | | | | | | | | | Why are people assigning booleans to string columns? >_> We unintentionally changed the behavior on Sqlite3 and PostgreSQL. Boolean values should cast to the database's representation of true and false. This is 't' and 'f' by default, and "1" and "0" on Mysql. The implementation to make the connection adapter specific behavior is hacky at best, and should be re-visted once we decide how we actually want to separate the concerns related to things that should change based on the database adapter. That said, this isn't something I'd expect to change based on my database adapter. We're storing a string, so the way the database represents a boolean should be irrelevant. It also seems strange for us to give booleans special behavior at all in string columns. Why is `to_s` not sufficient? It's inconsistent and confusing. Perhaps we should consider deprecating in the future. Fixes #17571
* Use the correct values for int max and minSean Griffin2014-10-311-9/+13
| | | | | We had accidentally gone one power of two too far. In addition, we need to handle minimum values as well as the maximum.
* Treat strings greater than int max value as out of rangeSean Griffin2014-10-313-3/+35
| | | | | | | | | | | Sufficiently large integers cause `find` and `find_by` to raise `StatementInvalid` instead of `RecordNotFound` or just returning `nil`. Given that we can't cast to `nil` for `Integer` like we would with junk data for other types, we raise a `RangeError` instead, and rescue in places where it would be highly unexpected to get an exception from casting. Fixes #17380
* edit pass over all warningsXavier Noria2014-10-281-3/+7
| | | | | | | | | | | | | | | This patch uniformizes warning messages. I used the most common style already present in the code base: * Capitalize the first word. * End the message with a full stop. * "Rails 5" instead of "Rails 5.0". * Backticks for method names and inline code. Also, converted a few long strings into the new heredoc convention.
* Fix typo in error message when non-boolean value is assigned to boolean columnPrathamesh Sonpatki2014-10-261-1/+1
|
* Add a deprecation warning for abiguous boolean valuesSean Griffin2014-10-161-1/+8
| | | | | | | | | | | In Rails 5.0, we'd like to change the behavior of boolean columns in Rails to be closer to Ruby's semantics. Currently we have a small set of values which are "truthy", and all others are "falsy". In Rails 5.0, we will reverse this to have a small number of values which are "falsy", and all others will become "truthy". In the interim, all values which are ambiguous must emit a deprecation warning.
* Allow YAML serialization when using TZ aware attributesSean Griffin2014-09-172-3/+17
|
* Correctly detect mutation on serialized columns mapping to binarySean Griffin2014-08-272-0/+15
| | | | Fixes #16701
* Implement `==` on `Type::Value` and `Attribute`Sean Griffin2014-08-151-0/+7
| | | | | This was a small self contained piece of the refactoring that I am working on, which required these objects to be comparable.
* [ci skip] fix spelling of overrideAkshay Vishnoi2014-08-131-2/+2
|
* Merge pull request #16333 from ↵Yves Senn2014-08-041-4/+17
|\ | | | | | | | | | | | | | | | | joker1007/fix_decimal_cast_from_float_with_large_precision Fix type casting to Decimal from Float with large precision Conflicts: activerecord/CHANGELOG.md
| * Fix type casting to Decimal from Float with ...joker10072014-08-011-4/+17
| | | | | | | | | | When I defines large precision column at RDBMS, I assigns float value, raise ArgumentError (precision too large).
* | Rename method for clarityCarlos Antonio da Silva2014-07-311-3/+3
|/ | | | Ruby generally does not use the is_* prefix on predicate methods.
* Prefer if/else for this caseRafael Mendonça França2014-07-171-3/+2
| | | | | One of the branches is using a proc to check if the value respond_to a method so it is better to not do case comparations
* Fix decimal_test module and add new test for object responding to to_dMariano Valles2014-07-161-1/+0
|
* Fix case statement to use ::Numeric and ::StringMariano Valles2014-07-161-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 11:01:16 +0000