| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
If set to `if_exists: true`, it generates a statement like:
DROP TABLE IF EXISTS posts
This syntax is supported in the popular SQL servers, that is (at least)
SQLite, PostgreSQL, MySQL, Oracle and MS SQL Sever.
Closes #16366.
|
| |
|
|
|
|
|
|
|
| |
When table has a composite primary key, the `primary_key` method for
sqlite3 and postgresql was only returning the first field of the key.
Ensures that it will return nil instead, as AR dont support composite pks.
|
| |
|
| |
|
|\
| |
| | |
Refactor `add_column_options!`, to move the quoting of default value for :uuid in `quote_value`.
|
| | |
|
| |
| |
| |
| | |
:uuid in `quote_value`.
|
|/ |
|
|
|
|
|
|
|
| |
This allows us so abstract the migration from the type that is actually
used by Rails. For example, ":string" may be a varchar or something,
but the framework does that translation, and the app shouldn't need to
know.
|
| |
|
|
|
|
|
|
|
|
| |
Also checked to make sure this does not affect foreign key constraints.
(It doesn't).
Fixes #12856
Closes #14088
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Skip setting sequence on a table create if the value is 0 since it will start the first value at 1 anyway.
This fixes the PG error 'setval: value 0 is out of bounds for sequence vms_id_seq...' encountered when migrating a new DB.
BugzID: 15452,9772,13475,16850
|
|
|
|
|
|
|
|
|
|
|
|
| |
While investigating #16951 I found that another library's monkey-patching of
`Enumerable` was causing the test migrations helper to break when trying to
build the `CREATE DATABASE` statement. The prior approach used `#sum` to build
the string from the options hash.
As the code that combines the options to build the database statement is not
user-facing, using `#inject` here instead will remove the only place where the
database creation/migration code is dependent on ActiveSupport's monkey-patching
of `Enumerable`.
|
|
|
|
|
|
| |
Closes #16907.
[Matthew Draper & Yves Senn]
|
|
|
|
|
|
|
|
|
| |
This is a reacon to https://github.com/rails/rails/commit/d6c1205584b1ba597db4071b168681678b1e9875#commitcomment-7502487
This backwards incompatibility was introduced with d6c12055 to fix #7516.
However both `connection.default_sequence_name` and `model.sequence_name` are public API.
The PostgreSQL adapter should honor the interface and return strings.
/cc @matthewd @chancancode
|
|
|
|
|
| |
* Require either FIRST or LAST qualifier for "NULLS ..."
* Require whitespace before "NULLS ..."
|
|
|
|
| |
Fixes #16623 introduced by https://github.com/rails/rails/commit/3d5a2019bcccc6fb01bee4811ca669f4383edb51
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #16261.
[Matthew Draper, Yves Senn]
Using `DEFAULT NULL` results in the same behavior as `DROP DEFAULT`.
However, PostgreSQL will cast the default to the columns type,
which leaves us with a default like "default NULL::character varying".
/cc @matthewd
|
|
|
|
|
|
|
|
| |
The only case where we got a column that was not `nil`, but did not
respond to `cast_type` was when type casting the default value during
schema creation. We can look up the cast type, and add that object to
the column definition. Will allow us to consistently rely on the type
objects for type casting in all directions.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is an intermediate solution. It is related to the refactoring @sgrif
is making and will change in the future.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Fixed #columns_for_distinct of postgresql adapter
Conflicts:
activerecord/CHANGELOG.md
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
- Create a consistent API across adapters for building new columns
- Use it for custom properties so we don't get `UndefinedMethodError`s
in stuff I'm implementing elsewhere.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Determining things like precision and scale in postgresql will require
the given blocks to take additional arguments besides the OID.
- Adds the ability to handle additional arguments to `TypeMap`
- Passes the column type to blocks when looking up PG types
|
| |
| |
| |
| | |
Partial revert of c0bfc3f412834ffe8327a15ae3a46602cc28e425
|
| | |
|
| |
| |
| |
| | |
redundant
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.
Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.
|