| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This reverts commit 6d5b1fdf55611de2a1071c37544933bb588ae88e.
`eager_load` and `references` can include hashes, which won't match up
with `references`
A test case has been added to demonstrate the problem
|
|\
| |
| | |
`ActiveRecord::Base#becomes` should copy the errors
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
This was changed in 421c81b, as `exists?` blows up if you are eager
loading a polymorphic association, as it'll try to construct a join to
that table. The previous change decided to execute a `count` instead,
which wouldn't join.
Of course, the only time we actually need to perform a join on the eager
loaded values (which would perform a left outer join) is if they're
being referenced in the where clause. This doesn't affect inner joins.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
Some backends allow `LIMIT 1,2` as a shorthand for `LIMIT 1 OFFSET 2`.
Supporting this in Active Record massively complicates using bind
parameters for limit and offset, and it's trivially easy to build an
invalid SQL query by also calling `offset` on the same `Relation`.
This is a niche syntax that is only supported by a few adapters, and can
be trivially worked around by calling offset explicitly.
|
|\
| |
| |
| |
| | |
yui-knk/add_test_sanitize_sql_array_handles_named_bind_variables
Add test cases for `#sanitize_sql_array` with named_bind_variables
|
| |
| |
| |
| |
| | |
And add code examples to `sanitize_sql_for_conditions`,
`sanitize_sql_for_assignment`, and `sanitize_sql_array`.
|
|\ \
| | |
| | | |
Use adapter supports_datetime_with_precision
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit c2e70ca9b042a3461aac0dc073a80e84bd77eb57, reversing
changes made to b0e5fc2737ed0b2f67f9b9538d01e084545493fd.
this broke the build
|
|\ \ \
| | | |
| | | | |
Remove unused deprecation notice
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The `rake db:test:*` tasks were deprecated in #13528, but were
undeprecated and added back in via #17739.
|
|\ \ \ \
| | | | |
| | | | | |
Typo correction
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In the doc the `dependent` option was set with: `dependent: destroy`.
This is not working because destroy would call the method of the activerecord::base object.
The right way is: `dependent: :destroy`
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The problem was that when saving an object, we would
call touch_later on the parent which wont be saved immediteally, and
it wont call any callbacks. That was working one level up because
we were calling touch, during the touch_later commit phase. However that still
didnt solve the problem when you have a 3+ levels of parents to be touched,
as calling touch would affect the parent, but it would be too late to run callbacks
on its grand-parent.
The solution for this, is instead, call touch_later upwards when the first
touch_later is called. So we make sure all the timestamps are updated without relying
on callbacks.
This also removed the hard dependency BelongsTo builder had with the TouchLater module.
So we can still have the old behaviour if TouchLater module is not included.
[fixes 5f5e6d924973003c105feb711cefdb726f312768]
[related #19324]
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This will also get the defaults from attribute definitions like:
attribute :type, :string, default: "SomethingElse"
|
| | | |
| | | |
| | | |
| | | | |
`has_attribute?` method to check wether a given attribute has been defined.
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
STI cast new instances to `default type` on initialize.
|
|/ / / /
| | | |
| | | |
| | | | |
fixes #17121
|
| | | |
| | | |
| | | |
| | | |
| | | | |
It appears that I missed this one when I delegated all the non-mutation
array methods that were not on Enumerable
|
|\ \ \ \
| |_|/ /
|/| | | |
Explain the connection pool error message better [ci skip]
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The previous message was misleading (especially for Ops guys) when
diagnosing problems related to the database connection.
The message was suggesting that the connection cannot be obtained which
normally assumes the need to look at the database.
But this isn't the case as the connection could not be retrieved from
the application's internal connection pool.
The new message should make it more explicit and remove the confusion.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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"
|
|\ \ \ \ \
| |_|/ / /
|/| | | | |
Refactor `AbstractAdapter#initialize`
|
| | | | |
| | | | |
| | | | |
| | | | | |
`pool` in args is unused anymore. And `config` is used in all adapters.
|
|\ \ \ \ \
| |/ / / /
|/| | | | |
Bugfix collection association #create method
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When same association is loaded in the model creation callback
The new object is inserted into association twice
|
| | | | |
| | | | |
| | | | |
| | | | | |
Not needed for `Mysql2Adapter` and `AbstractMysqlAdapter`.
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Add prepared statements support for `Mysql2Adapter`
|
| | | | | | |
|
|/ / / / /
| | | | |
| | | | |
| | | | | |
[ci skip]
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
kamipo/schema_dumping_support_for_postgresql_geometric_types
Add schema dumping support for PostgreSQL geometric data types
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
kamipo/not_passing_native_database_types_to_table_definition
Not passing `native_database_types` to `TableDefinition`
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The `native_database_types` only used in `TableDefinition` for look up
the default `:limit` option. But this is duplicated process with
`type_to_sql`. Passing `native_database_types` is not needed.
|
|\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
kamipo/set_field_encoding_is_only_needed_for_mysql_adapter
`set_field_encoding` is only needed for `MysqlAdapter`
|
| | |/ / / / /
| |/| | | | |
| | | | | | |
| | | | | | | |
Not needed for `Mysql2Adapter` and `AbstractMysqlAdapter`.
|
|\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
Update and fix forbidden attributes test issues caused by AC::Parameters change
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Add AC::Parameters tests for WhereChain#not
|
| |_|/ / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
As was pointed out by #17128, our blacklist of mutation methods was
non-exhaustive (and would need to be kept up to date with each new
version of Ruby). Now that `Relation` includes `Enumerable`, the number
of methods that we actually need to delegate are pretty small. As such,
we can change to explicitly delegating the few non-mutation related
methods that `Array` has which aren't on `Enumerable`
|
|\ \ \ \ \ \
| |_|_|/ / /
|/| | | | | |
Add example for AR::Persistence#toggle
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|