| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the `5.0.0.beta1` release, the CHANGELOGs got an entry like the
following:
```
* No changes.
```
It is kinda confusing as there are indeed changes after it. Not a
biggie, just a small pass over the CHANGELOGs.
[ci skip]
|
|\
| |
| |
| |
| |
| |
| | |
Pass group values when including association
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| | |
Fixes problem when added `group()` in association scope was lost
in eager loaded association.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | | |
ActiveRecord::Base#find(array) returning result in the same order as the array passed
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | | |
byroot/do-not-include-column-limit-if-it-is-default
Do not include column limit in schema.rb if it matches the default
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Support passing the schema name prefix to `conenction.indexes`
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Support passing the schema name as a prefix to table name in
`ConnectionAdapters::SchemaStatements#indexes`. Previously the prefix would
be considered a full part of the index name, and only the schema in the
current search path would be considered.
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Ignore index name in `index_exists?` when not passed a name to check for
|
| | |_|_|/
| |/| | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Remove legacy mysql adapter
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The changelog entry for ApplicationRecord was a bit confusing. Thank you
guys for helping me get it in a better shape.
[ci skip]
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.
Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.
Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We currently generate an unbounded number of prepared statements when
`limit` or `offset` are called with a dynamic argument. This changes
`LIMIT` and `OFFSET` to use bind params, eliminating the problem.
`Type::Value#hash` needed to be implemented, as it turns out we busted
the query cache if the type object used wasn't exactly the same object.
This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`.
Doing this relied on AR internals, and was never officially supported
usage.
Fixes #22250.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Those are actually shortcuts for `after_commit`.
Before:
after_commit :add_to_index_later, on: :create
after_commit :update_in_index_later, on: :update
after_commit :remove_from_index_later, on: :destroy
After:
after_create_commit :add_to_index_later
after_update_commit :update_in_index_later
after_destroy_commit :remove_from_index_later
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[ci skip]
Q: What happens if you initialize an AR model by passing Parameters that
have not been whitelisted with `permit`?
A: An `ActiveModel::ForbiddenAttributesError` is raised.
I think this behavior is correct, and it's better than what used to happen,
with unpermitted parameter being simply ignored.
|
|\ \ \
| | | |
| | | |
| | | | |
STI cast new instances to `default type` on initialize.
|
|/ / /
| | |
| | |
| | | |
fixes #17121
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix rake db:structure:dump on Postgres when multiple schemas are used
Conflicts:
activerecord/CHANGELOG.md
Closes #22346.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If postgresql is being used and there are multiple schemas listed on the
`schema_search_path`, then `structure.sql` dumps (triggered by `rake
db:structure:dump` or `config.active_record.schema_format = :sql`) began
failing in Rails 4.2.5.
This is due to the changes made in
https://github.com/rails/rails/pull/17885 The problem is that multiple
schemas were getting getting passed to `Kernel.system` as a single,
space delimited string argument (for example, "--schema=foo
--schema=bar"). However, with the updated array style of calling
`Kernel.system`, these need to be passed as separate arguments (for
example, "--schema=foo", "--schema=bar"). If they get passed as a single
string, then the underlying pg_dump program isn't sure how to interpret
that single argument and you'll get an error reporting: "pg_dump: No
matching schemas were found"
|
| | | | |
|
| | | | |
|
| | | | |
|
|/ / / |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 8246b593bff71f2cebf274c133bb8917f1e094c8.
There was concern about this modifying the behavior of past migrations.
We're going to add an way to modify the migration generator instead.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's often the case that you want to have an option that you cannot
specify at the database level, but want applied to *all* tables that you
create. For example, you might want to specify `ROW_FORMAT=DYNAMIC` to
not have to limit text columns to length 171 for indexing when using
utf8mb4. This allows an easy way to specify this in your database
configuration.
While this change affects both MySQL and MySQL2, the test only covers
MySQL2, as the legacy mysql adapter appears to always return ASCII
strings, and is tangential to what we're actually doing.
|