aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/connection_adapters/type_lookup_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* Map :bigint as NUMBER(19) sql_type by using `:limit => 19` for OracleYasuo Honda2015-06-011-1/+5
| | | | | | | | | | | | | | | | | | | since NUMBER(8) is not enough to store the maximum number of bigint. Oracle NUMBER(p,0) as handled as integer because there is no dedicated integer sql data type exist in Oracle database. Also NUMBER(p,s) precision can take up to 38. p means the number of digits, not the byte length. bigint type needs 19 digits as follows. $ irb 2.2.2 :001 > limit = 8 => 8 2.2.2 :002 > maxvalue_of_bigint = 1 << ( limit * 8 - 1) => 9223372036854775808 2.2.2 :003 > puts maxvalue_of_bigint.to_s.length 19 => nil 2.2.2 :004 >
* `type_cast_from_user` -> `cast`Sean Griffin2015-02-171-1/+1
|
* Properly lookup the limit for bigintSean Griffin2015-02-021-0/+5
| | | | Fixes #18787.
* Rename `type_cast` to `type_cast_from_database`Sean Griffin2014-06-091-1/+1
| | | | | | | | 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.
* Remove special case in schema dumper for decimal without scaleSean Griffin2014-05-231-6/+10
|
* Remove :timestamp column typeSean Griffin2014-05-191-5/+2
| | | | | | | | | | | | The `:timestamp` type for columns is unused. All database adapters treat them as the same database type. All code in `ActiveRecord` which changes its behavior based on the column's type acts the same in both cases. However, when the type is passed to code that checks for the `:datetime` type, but not `:timestamp` (such as XML serialization), the result is unexpected behavior. Existing schema definitions will continue to work, and the `timestamp` type is transparently aliased to `datetime`.
* Delegate `Column#type` to the injected type objectSean Griffin2014-05-191-0/+100
The decision to wrap type registrations in a proc was made for two reasons. 1. Some cases need to make an additional decision based on the type (e.g. a `Decimal` with a 0 scale) 2. Aliased types are automatically updated if they type they point to is updated later. If a user or another adapter decides to change the object used for `decimal` columns, `numeric`, and `number` will automatically point to the new type, without having to track what types are aliased explicitly. Everything else here should be pretty straightforward. PostgreSQL ranges had to change slightly, since the `simplified_type` method is gone.