| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Some databases like MySQL allow defining collation charset for specific
columns.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1502caefd30b137fd1a0865be34c5bbf85ba64c1.
The test suite for the mysql adapter broke when this commit was used
with MySQL 5.6.
Conflicts:
activerecord/CHANGELOG.md
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Fixes #18787.
|
|
|
|
|
|
|
|
| |
`bound_attributes` is now used universally across the board, removing
the need for the conversion layer. These changes are mostly mechanical,
with the exception of the log subscriber. Additional, we had to
implement `hash` on the attribute objects, so they could be used as a
key for query caching.
|
|
|
|
|
|
|
| |
I'm planning on deprecating the column argument to mirror the
deprecation in [arel].
[arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
|
|
|
|
|
|
|
|
| |
Previosly count and other AR calculations would convert
column_name_for_operation to sql on a default Arel::Table.engine
(AR::Base) connection. That could lead to trouble if current
model has a connection to a different adapter or Base connection
is inaccessible.
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
fix for messages in invalid encoding from db-drivers
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract_adapter.rb
activerecord/test/cases/connection_adapters/abstract_adapter_test.rb
|
| | |
|
|\ \
| | |
| | |
| | | |
Clear query cache on rollback
|
| | | |
|
| | |
| | |
| | |
| | | |
/cc @sgrif
|
|/ /
| |
| |
| | |
Move microseconds formatting to `AbstractAdapter`.
|
| |
| |
| |
| | |
We can't change the signature without a deprecation cycle.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This makes the following changes:
* warn if `:null` is not passed to `add_timestamps`
* `timestamps` method docs link to `add_timestamps` docs
* explain where additional options go
* adjust examples to include `null: false` (to prevent deprecation warnings)
|
| |
| |
| |
| | |
Oh hey, we got to remove some code because of that!
|
| |
| |
| |
| |
| |
| | |
Arel handles this for us automatically. Updated tests, as BindParam is
no longer a subclass of SqlLiteral. We should remove the second argument
to substitute_at entirely, as it's no longer used
|
| | |
|
| |
| |
| |
| |
| | |
MySQL reports the column name as `"MAX(developer_id)"`. PG will report
it as `"max"`
|
| |
| |
| |
| |
| |
| | |
We end up re-ordering them either way when we construct the Arel AST (in order
to deal with rewhere, etc), so we shouldn't bother giving it a number in the
first place beforehand.
|
| |
| |
| |
| |
| |
| |
| | |
`AbstractAdapter#supports_views?` defaults to `false` so we have to turn it on
in adapter subclasses. Currently the flag only controls test execution.
/cc @yahonda
|
| | |
|
| | |
|
| |
| |
| |
| | |
Also add test to assets the savepoint name
|
| |
| |
| |
| |
| |
| |
| | |
Add a transaction manager per connection, so it can controls the
connection responsibilities.
Delegate transaction methods to transaction_manager
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The finishing variable on the transaction object was a work-around for
the savepoint name, so after a rollback/commit the savepoint could be
released with the previous name.
related:
9296e6939bcc786149a07dac334267c4035b623a
60c88e64e26682a954f7c8cd6669d409ffffcc8b
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Follow up to #15438 and #15502.
/cc @sgrif
|
| |
| |
| |
| |
| |
| | |
- 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.
|
| | |
|
| |
| |
| |
| |
| | |
`ActiveRecord::ConnectionAdapters::Type::Value` =>
`ActiveRecord::Type::Value`
|
| |
| |
| |
| |
| |
| | |
With ActiveRecord::Properties, we now have a reasonable path for users
to continue to keep this behavior if they want it. This is an edge case
that has added a lot of complexity to the code base.
|
| | |
|
| |
| |
| |
| |
| | |
Columns and injected types no longer have any conditionals based on the
format of SQL type strings! Hooray!
|
| | |
|
| |
| |
| |
| |
| |
| | |
Ideally types will be usable without having to specify a sql type
string, so we should keep the information related to parsing them on the
adapter or another object.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
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`.
|
| | |
|
| | |
|
| | |
|
| | |
|