| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Honour joining model order in `has_many :through` associations when
eager loading
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
association when eager loading.
Previously, eager loading a `has_many :through` association with no
defined order would return the records in the natural order of the
database. Now, these records will be returned in the order that the
joining record is returned, in case there is a defined order there.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I ran into an issue where validations on a suppressed record were
causing validation errors to be thrown on a record that was never going
to be saved.
There isn't a reason to run the validations on a record that doesn't
matter.
This change moves the suppressor up the chain to be run on the `save` or
`save!` in the validations rather than in persistence. The issue with
running it when we hit persistence is that the validations are run
first, then we hit persistance, and then we hit the suppressor. The
suppressor comes first.
The change to the test was required since I added the
`validates_presence_of` validations. Adding this alone was enough to
demonstrate the issue. I added a new test to demonstrate the new
behavior is explict.
|
| |
| |
| |
| | |
Adds changelog headers for beta3 release
|
| |
| |
| |
| |
| | |
I had to revert changes made for this CHANGELOG entry so this is no
longer valid. The change for this entry was removed in 2c02bc0.
|
| |
| |
| |
| | |
Mutating the result of Relation#to_a should not affect the relation
|
| |
| |
| |
| |
| | |
`#` was removed at f57092a but this `#` is intentional.
e.g. https://github.com/rails/rails/blame/v5.0.0.beta2/activerecord/CHANGELOG.md#L1423-L1426
|
| |
| |
| | |
This was showing up as an H1. Fixing the indentation here fixes the codeblock.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
different types.
When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array.
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2))
This is fixed to properly look for any records matching both type and id:
PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
# => SELECT "price_estimates".* FROM "price_estimates"
WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1)
OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Let t.foreign_key use the same `to_table` twice
Conflicts:
activerecord/CHANGELOG.md
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously if you used `t.foreign_key` twice within the same
`create_table` block using the same `to_table`, all statements except
the final one would fail silently. For example, the following code:
def change
create_table :flights do |t|
t.integer :from_id, index: true, null: false
t.integer :to_id, index: true, null: false
t.foreign_key :airports, column: :from_id
t.foreign_key :airports, column: :to_id
end
end
Would only create one foreign key, on the column `from_id`.
This commit allows multiple foreign keys to the same table to be created
within one `create_table` block.
|
|\ \ \
| |/ /
|/| |
| | | |
Add missing CHANGELOG for regression fix in #18155 which fixes #13387
|
|/ /
| |
| |
| | |
[ci skip]
|
|\ \
| | |
| | | |
Fix AR::Relation#last bugs instroduced in 7705fc
|
| | |
| | |
| | |
| | | |
instead of loading the relation into memory
|
|/ /
| |
| |
| | |
The author name was lost in the merge commit 6fedc7d.
|
| |
| |
| | |
since starting with Rails 5.x(beta) we prefer to use rails as the replacement of rake commands, may be change log will be the same
|
|\ \
| | |
| | |
| | |
| | |
| | | |
Allow `joins` to be unscoped
Fixes #13775
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Added numeric helper into `SchemaStatements` for MySQL and PostgreSQL
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With this addition, you can add a column into the table like:
```
create_table(:numeric_types) do |t|
t.numeric :foo, precision: 10, scale: 2, default: 2.0
end
```
The result of the migration above is same with:
```
create_table(:numeric_types) do |t|
t.decimal :foo, precision: 10, scale: 2, default: 2.0
end
```
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 99801c6a7b69eb4b006a55de17ada78f3a0fa4c1.
Ultimately it doesn't matter whether `add_index` or `t.index` are used
in the schema dumper in any meaningful way. There are gems out there
which hook into the old behavior for things like indexing materialized
views. Since the reverted commit doesn't seem to add much benefit,
there's no reason for us to break these gems.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
And improve changelongs.
[ci skip]
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 9f3730a516f30beb0050caea9539f8d6b808e58a, reversing
changes made to 2637fb75d82e1c69333855abd58c2470994995d3.
There are additional issues with this commit that need to be addressed
before this change is ready (see #23377). This is a temporary revert in
order for us to have more time to address the issues with that PR,
without blocking the release of beta2.
|
| |
| |
| |
| | |
instead of loading relation
|
| |
| |
| |
| |
| | |
Raises when #reverse_order can not process SQL order instead of making
invalid SQL before this patch
|
| |
| |
| |
| |
| |
| |
| | |
We found that inserting all 600 schema_migrations for our mid-sized app takes about a minute on a cloud based CI environment.
I assume that the original code did not use multi-row-insert because SQLite3 was not supporting the syntax back then,
but it's been supported since 3.7.11: http://www.sqlite.org/releaselog/3_7_11.html
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Using `references` or `belongs_to` in migrations will always add index
for the referenced column by default, without adding `index:true` option
to generated migration file.
- Users can opt out of this by passing `index: false`.
- Legacy migrations won't be affected by this change. They will continue
to run as they were before.
- Fixes #18146
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Closes #21986.
This makes it possible to write custom types that define a different
mapping for STI columns.
|
| |
| |
| |
| |
| |
| | |
instead of start_at/end_at based on comments
at https://github.com/rails/rails/pull/12257#issuecomment-74688344
|
|\ \
| | |
| | | |
Add `:expression` option support on the schema default
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Example:
create_table :posts do |t|
t.datetime :published_at, default: -> { 'NOW()' }
end
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
glittershark/if-and-unless-in-secure-token"
This reverts commit 224eddfc0eeff6555ae88691306e61c7a9e8b758, reversing
changes made to 9d681fc74c6251d5f2b93fa9576c9b2113116680.
When merging the pull request, I misunderstood `has_secure_token` as declaring a model
has a token from birth and through the rest of its lifetime.
Therefore, supporting conditional creation doesn't make sense. You should never mark a
model as having a secure token if there's a time when it shouldn't have it on creation.
|
| | |
|
| |
| |
| |
| | |
Closes #22584.
|
| |
| |
| |
| | |
Closes #23021.
|
| |
| |
| |
| |
| | |
Pass through :if and :unless options from has_secure_token to the
generated before_create callback
|
| |
| |
| |
| | |
[ci skip]
|
|\ \
| | |
| | |
| | | |
Add short-hand methods for text and blob types in MySQL
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Pg and Sqlite3, `:text` and `:binary` have variable unlimited length.
But in MySQL, these have limited length for each types (ref #21591, #21619).
This change adds short-hand methods for each text and blob types.
Example:
create_table :foos do |t|
t.tinyblob :tiny_blob
t.mediumblob :medium_blob
t.longblob :long_blob
t.tinytext :tiny_text
t.mediumtext :medium_text
t.longtext :long_text
end
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
While the type definition is in Active Model the change of behavior will
be only user facing in Active Record so better to put the entry in its
changelog.
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I realized that `first(2)`, etc. was unnecessarily querying for the
records when they were already preloaded. This was because
`find_nth_with_limit` can not know which `@records` to return because
it conflates the `offset` and `index` into a single variable, while
the `@records` only needs the `index` itself to select the proper
record.
Because `find_nth` and `find_nth_with_limit` are public methods, I
instead introduced a private method `find_nth_with_limit_and_offset`
which is called internally and handles the `loaded?` checking.
Once the `offset` argument is removed from `find_nth`,
`find_nth_with_limit_and_offset` can be collapsed into
`find_nth_with_limit`, with `offset` always equal to `offset_index`.
|
| |
| |
| |
| |
| |
| |
| |
| | |
All uses of the `offset` are passing `offset_index`. Better to push
down the `offset` consideration into `find_nth`.
This also works toward enabling `find_nth_with_limit` to take
advantage of the `loaded?` state of the relation.
|
| |
| |
| |
| | |
[ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
methyl/fix-includes-for-groupped-association"
This reverts commit 537ac7d6ade61e95f2b70685ff2236b7de965bab, reversing
changes made to 9c9c54abe08d86967efd3dcac1d65158a0ff74ea.
Reason:
The way we preload associations will change the meaning of GROUP BY
operations. This is illustrated in the SQL generated by the added
test (failing on PG):
Association Load:
D, [2015-12-21T12:26:07.169920 #26969] DEBUG -- : Post Load (0.7ms) SELECT "posts".* FROM "posts" LEFT JOIN comments ON comments.post_id = posts.id WHERE "posts"."author_id" = $1 GROUP BY posts.id ORDER BY SUM(comments.tags_count) [["author_id", 1]]
Preload:
D, [2015-12-21T12:26:07.128305 #26969] DEBUG -- : Post Load (1.3ms) SELECT "posts".* FROM "posts" LEFT JOIN comments ON comments.post_id = posts.id WHERE "posts"."author_id" IN (1, 2, 3) GROUP BY posts.id ORDER BY SUM(comments.tags_count)
|