| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We support this behavior, but have no tests which assert that type
casting actually occurs.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
We need to re-order the bind parameters since the AST returned by the
relation will have the where statement as the first bp, which breaks on
PG.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
MySQL reports the column name as `"MAX(developer_id)"`. PG will report
it as `"max"`
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
It was transitively relying on the vertex model being loaded
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.
There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)
[Melanie Gilman & Sean Griffin]
|
|\ \ \ \
| | | | |
| | | | | |
Remove redundant substitute index when constructing bind values
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |/ / /
|/| | |
| | | |
| | | |
| | | | |
This slightly simplifies the code, and reduces the number of times we
need to iterate over the attributes by one.
|
| | | | |
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Nothing is directly using the columns for the default values anymore.
This step helps us get closer not not mutating the columns hash.
|
| | |
| | |
| | |
| | | |
Fixes #17170
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
ziggythehamster/activerecord-connectionhandling-RAILS_ENV-without-rails
If Rails is not defined, check ENV["RAILS_ENV"] and ENV["RACK_ENV"] in ActiveRecord::ConnectionHandling
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes a regression introduced by 6cc03675d30b58e28f585720dad14e947a57ff5b.
ActiveRecord, if used without Rails, always checks the "default_env" environment. This would be OK, except that Sinatra also supports environments,
and it runs with {RACK|RAILS}_ENV=production. This patch adds a fallback to RAILS_ENV and RACK_ENV (and ultimately default_env) if Rails.env doesn't exist.
|
| | |
| | |
| | |
| | |
| | | |
We had accidentally gone one power of two too far. In addition, we need
to handle minimum values as well as the maximum.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | | |
It is internal use only. This is to avoid conflicting with users' method
names. Fixes #17458
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Arel has changed so that `.sum` no longer aliases `SUM(the_column)` to
`sum_id`. This means the type returned by the adapter will be at the key
`"SUM(the_column)"`. Longer term, we should eventually be able to retain
type information from the AR::Base subclasses used in joined queries
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Remove redundant `to_s` in interpolation
|
| | | | |
|
|/ / /
| | |
| | |
| | | |
Passing ranges to `#in` has been deprecated in Arel.
|
|\ \ \
| | | |
| | | | |
Remove redundant `to_s` in interpolation
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
mcfiredrill/doc-change-column-default-abstract-mysql-adapter
document change_column and change_column_default for abstract_mysql_adapter [ci skip]
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The MySQLAdapter type map used the lowest priority for enum types.
This was the result of a recent refactoring and lead to some broken lookups
for enums with values that match other types. Like `8bit`.
This patch restores the priority to what we had before the refactoring.
/cc @sgrif
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
let warn with heredocs
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.
Heredocs have better readability, and with `squish` we can still
produce a single line.
This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.
|
| | | |
| | | |
| | | |
| | | | |
We were relying on hash inequality in tests
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The query cache uses bind values as hash keys. The current
implementation relies on reference equality for hash equality. This is
brittle, and can easily break in the future.
|
| | | |
| | | |
| | | |
| | | | |
We shouldn't rely on reference equality of these objects in tests
|
| | | |
| | | |
| | | |
| | | | |
The value methods will default to an empty array for us automatically
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The change to accessing keys directly was originally added to allow
`merge` to take a hash. The implementation of `HashMerger` no longer
requires us to be doing so. Accessing the values directly makes it
impossible to change internal storage details, even if shim methods are
added temporarily
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
Raises ArgumentError when try to define a scope without a callable
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
This changes the actual exception `NoMethodError: undefined method `call'
for #<ActiveRecord::Relation []>` to a `ArgumentError` when try to define
a scope without a callable.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use type column first in multi-column indexes
Conflicts:
activerecord/CHANGELOG.md
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`add_reference` can very helpfully add a multi-column index when you use
it to add a polymorphic reference. However, the first column in the
index is the `id` column, which is less than ideal.
The [PostgreSQL docs][1] say:
> A multicolumn B-tree index can be used with query conditions that
> involve any subset of the index's columns, but the index is most
> efficient when there are constraints on the leading (leftmost)
> columns.
The [MySQL docs][2] say:
> MySQL can use multiple-column indexes for queries that test all the
> columns in the index, or queries that test just the first column, the
> first two columns, the first three columns, and so on. If you specify
> the columns in the right order in the index definition, a single
> composite index can speed up several kinds of queries on the same
> table.
In a polymorphic relationship, the type column is much more likely to be
useful as the first column in an index than the id column. That is, I'm
more likely to query on type without an id than I am to query on id
without a type.
[1]: http://www.postgresql.org/docs/9.3/static/indexes-multicolumn.html
[2]: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
|
|\ \ \
| | | |
| | | | |
Fix Relation#rewhere to work with Range values
|