- 19 5月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 04 3月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 04 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
The type from the column is never used, except when being passed to the attributes API. While leaving the type on the column wasn't necessarily a bad thing, I worry that it's existence there implies that it is something which should be used. During the design and implementation process of the attributes API, there have been plenty of cases where getting the "right" type object was hard, but I had easy access to the column objects. For any contributor who isn't intimately familiar with the intents behind the type casting system, grabbing the type from the column might easily seem like the "correct" thing to do. As such, the goal of this change is to express that the column is not something that should be used for type casting. The only places that are "valid" (at the time of this commit) uses of acquiring a type object from the column are fixtures (as the YAML file is going to mirror the database more closely than the AR object), and looking up the type during schema detection to pass to the attributes API Many of the failing tests were removed, as they've been made obsolete over the last year. All of the PG column tests were testing nothing beyond polymorphism. The Mysql2 tests were duplicating the mysql tests, since they now share a column class. The implementation is a little hairy, and slightly verbose, but it felt preferable to going back to 20 constructor options for the columns. If you are git blaming to figure out wtf I was thinking with them, and have a better idea, go for it. Just don't use a type object for this.
-
- 31 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
The goal is to remove the type object from the column, and remove columns from the type casting process entirely. The primary motivation for this is clarity. The connection adapter does not have sufficient type information, since the type we want to work with might have been overriden at the class level. By taking this object from the column, it is easy to mistakenly think that the column object which exists on the connection adapter is sufficient. It isn't. A concrete example of this is `serialize`. In 4.2 and earlier, `where` worked in a very inconsistent and confusing manner. If you passed a single value to `where`, it would serialize it before querying, and do the right thing. However, passing it as part of an array, hash, or range would cause it to not work. This is because it would stop using prepared statements, so the type casting would come from arel. Arel would have no choice but to get the column from the connection adapter, which would treat it as any other string column, and query for the wrong value. There are a handful of cases where using the column object to find the cast type is appropriate. These are cases where there is not actually a class involved, such as the migration DSL, or fixtures. For all other cases, the API should be designed as such that the type is provided before we get to the connection adapter. (For an example of this, see the work done to decorate the arel table object with a type caster, or the introduction of `QueryAttribute` to `Relation`). There are times that it is appropriate to use information from the column to change behavior in the connection adapter. These cases are when the primitive used to represent that type before it goes to the database does not sufficiently express what needs to happen. An example of this that affects every adapter is binary vs varchar, where the primitive used for both is a string. In this case it is appropriate to look at the column object to determine which quoting method to use, as this is something schema dependent. An example of something which would not be appropriate is to look at the type and see that it is a datetime, and performing string parsing when given a string instead of a date. This is the type of logic that should live entirely on the type. The value which comes out of the type should be a sufficiently generic primitive that the adapter can be expected to know how to work with it. The one place that is still using the column for type information which should not be necessary is the connection adapter type caster which is sometimes given to the arel table when we can't find the associated table. This will hopefully go away in the near future.
-
- 04 1月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
Slightly refactoring `PostgreSQLColumn`. `array` should be readonly. `default_function` should be initialized by `super`. `sql_type` has been removed `[]`. Since we already choose to remove it we should not change.
-
- 29 12月, 2014 1 次提交
-
-
由 Ryuta Kamizono 提交于
If it is not a default primary key, correctly dump the type and options.
-
- 05 7月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 10 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 30 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Many of the methods defined in `AttributeMethods::Serialization` can be refactored onto this type as well, but this is a reasonable small step. Removes the `Type` class, and the need for `decorate_columns` to handle serialized types.
-
- 24 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 23 5月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
Columns and injected types no longer have any conditionals based on the format of SQL type strings! Hooray!
-
-
- 22 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 21 5月, 2014 4 次提交
-
-
由 Yves Senn 提交于
- `extract_precision`, `extract_limit`, and `extract_default` probably need to follow. - would be good to remove the delegation `Column#extract_scale`. /cc @sgrif
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
All subclasses of column were now delegating `type_cast` to their injected type object. We can remove the overriding methods, and generalize it on the `Column` class itself. This also enabled us to remove several column classes completely, as they no longer had any meaningful behavior of their own.
-
- 19 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
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.
-
- 18 5月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Part of #15134. In order to perform typecasting polymorphically, we need to add another argument to the constructor. The order was chosen to match the `oid_type` on `PostgreSQLColumn`.
-
- 15 5月, 2014 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 14 5月, 2014 2 次提交
- 09 5月, 2014 1 次提交
-
-
由 Vijay Dev 提交于
-
- 08 5月, 2014 1 次提交
-
-
由 schneems 提交于
-
- 01 4月, 2014 1 次提交
-
-
由 Yves Senn 提交于
I ran the whole test suite and compared the old to the new types. Following is the list of types that did change with this patch: ``` DIFFERENT TYPE FOR mood: NEW: enum, BEFORE: DIFFERENT TYPE FOR floatrange: NEW: floatrange, BEFORE: float ``` The `floatrange` is a custom type. The old type `float` was simply a coincidence form the name `floatrange` and our type-guessing.
-
- 31 3月, 2014 1 次提交
-
-
由 Yves Senn 提交于
We have `connection_adapters/column.rb` so it's easier to remember that the column in in a separate file.
-