| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| | |
Bump minimum SQLite version to 3.8
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These OS versions have SQLite 3.8 or higher by default.
- macOS 10.10 (Yosemite) or higher
- Ubuntu 14.04 LTS or higher
Raising the minimum version of SQLite 3.8 introduces these changes:
- All of bundled adapters support `supports_multi_insert?`
- SQLite 3.8 always satisifies `supports_foreign_keys_in_create?` and `supports_partial_index?`
- sqlite adapter can support `alter_table` method for foreign key referenced tables by #32865
- Deprecated `supports_multi_insert?` method
|
|/
|
|
|
| |
To prevent redundant `to_s` like https://github.com/rails/rails/pull/32923#discussion_r189460008
automatically in the future.
|
|
|
|
| |
So do not expose `PostgreSQLTypeMetadata` in the doc too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a real (non-savepoint) transaction has committed or rolled back,
the original persistence-related state for all records modified in that
transaction is discarded or restored, respectively.
When the model has transactional callbacks, this happens synchronously
in the `committed!` or `rolled_back!` methods; otherwise, it happens
lazily the next time the record's persistence-related state is accessed.
The synchronous code path always finalizes the state of the record, but
the lazy code path only pops one "level" from the transaction counter,
assuming it will always reach zero immediately after a real transaction.
As the test cases included here demonstrate, that isn't always the case.
By using the same logic as the synchronous code path, we ensure that the
record's state is always updated after a real transaction has finished.
|
|
|
|
|
| |
Originally `SingularAssociation#replace` abstract method is private, and
doesn't intend to be called directly.
|
|
|
|
| |
Follow up of #19171 and #26825.
|
|\
| |
| | |
Add available transformations to docs
|
| |
| |
| |
| | |
`foreign_key`, `json` and `virtual` are also available.
|
|\ \
| | |
| | | |
Remove ActiveRecord::Transactions#rollback_active_record_state!
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`rollback_active_record_state!` was removed from `save!` but not `save`
in da840d13da865331297d5287391231b1ed39721b. I believe that leaving it
in `save` was a mistake, since that commit was intended to move the
rollback logic from the `save`/`save!` call to the transaction stack.
As of 67d8bb963d5d51fc644d6b1ca20164efb4cee6d7 the record's original
state is lazily restored the first time it's accessed after the
transaction, instead of when a rollback occurs. This means that the call
to `restore_transaction_record_state` here has no effect: the record's
transaction level is incremented twice (in rollback_active_record_state!
and `with_transaction_returning_status`), isn't decremented again until
the the `ensure` block runs, and won't hit zero until the next time
`sync_with_transaction_state` is called.
|
|\ \
| |/
|/| |
Don't clear transaction state after manual rollback
|
| |
| |
| |
| |
| |
| |
| | |
If an `ActiveRecord::Rollback` error was raised by a persistence method
(e.g. in an `after_save` callback), this logic would potentially discard
the original state of the record from before the transaction, preventing
it from being restored later when the transaction was rolled back.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`after_initialize`
`becomes` creates new object and copies attributes from the receiver. If
new object has mutation tracker which is created in `after_initialize`,
it should be cleared since it is for discarded attributes.
But if the receiver doesn't have mutation tracker yet, it will not be
cleared properly.
It should be cleared regardless of whether the receiver has mutation
tracker or not.
Fixes #32867.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the documentation for the newly introduced (in 5.1) AR::Dirty
methods was misleading, as it stated the the new methods were aliases
for the old methods. This was false, and caused confusion when the
differences in their implementation became apparent.
This change attempts to describe the behaviour of these methods more
accurately, also noting when they are likely to be useful (i.e. before
or after saving a record).
This change also makes minor updates to consistently format the
documentation of this API, in accordance with the API Documentation
Guidelines.
|
|
|
|
| |
Commit callbacks are intentionally disabled when errors occur when calling the callback chain in order to reset the internal record state. However, the implicit order of operations on the logic for checking if callbacks are disabled is wrong. The result is that callbacks can be unexpectedly when errors occur in transactions.
|
|
|
|
| |
If a 'has one' object is created from a new record, an ActiveRecord::RecordNotSaved error is raised but this behavior was also applied to the reverse scenario.
|
|
|
|
|
| |
The merging order was accidentally changed at #32447. The original
intention is force `drop_table ... if_exists: true`. #28070.
|
|
|
|
|
| |
* Singular associations don't define `#association.nil?`
* Wrap with <tt> for each method, not the whole sentence
|
|
|
|
|
|
|
| |
Currently `ids_reader` doesn't respect dirty target when the target is
not loaded yet unlike `collection.size`. I believe the inconsistency is
a bug, fixes the `ids_reader` to behave consistently regardless of
whether target is loaded or not.
|
|
|
|
|
|
|
| |
Already loaded associations were running an extra query when `size` was called on the association.
This fix ensures that an extra query is no longer run.
Update tests to use proper methods
|
|
|
|
| |
Not required after https://github.com/rails/arel/pull/449
|
|
|
|
|
|
| |
Adds test case for failing issue
Moves set_value back to protected
|
|\
| |
| | |
Merge Arel
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Update schema.rb documentation [CI SKIP]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The documentation previously claimed that `db/schema.rb` was "the
authoritative source for your database schema" while simultaneously
also acknowledging that the file is generated. These two statements are
incongruous and the guides accurately call out that many database
constructs are unsupported by `schema.rb`. This change updates the
comment at the top of `schema.rb` to remove the assertion that the file
is authoritative.
The documentation also previously referred vaguely to "issues" when
re-running old migrations. This has been updated slightly to hint at the
types of problems that one can encounter with old migrations.
In sum, this change attempts to more accurately capture the pros, cons,
and shortcomings of the two schema formats in the guides and in the
comment at the top of `schema.rb`.
[Derek Prior & Sean Griffin]
Co-authored-by: Sean Griffin <sean@seantheprogrammer.com>
|
| | |
| | |
| | |
| | | |
https://github.com/sparklemotion/sqlite3-ruby/blob/v1.3.13/lib/sqlite3/statement.rb#L101-L104
|
| | |
| | |
| | |
| | | |
There's no need to wrap the statement in a hash with a single key.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
samdec/multiple-has-one-through-associations-build-bug
Fix .new with multiple through associations
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes a bug with building an object that has multiple
`has_many :through` associations through the same object.
Previously, when building the object via .new, the intermediate
object would be created instead of just being built.
Here's an example:
Given a GameBoard, that has_one Owner and Collection through Game.
The following line would cause a game object to be created in the
database.
GameBoard.new(owner: some_owner, collection: some_collection)
Whereas, if passing only one of those associations into `.new` would
cause the Game object to be built and not created in the database.
Now the above code will only build the Game object, and not save it.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
So `target.is_a?(Array)` is meaningless, and just use `target.empty?`
instead of `target.blank?`.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Add `touch_all` method to `ActiveRecord::Relation`
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Allow `primary_key` argument to `empty_insert_statement_value`
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
to support Oracle database support identity data type
Oracle database does not support `INSERT .. DEFAULT VALUES`
then every insert statement needs at least one column name specified.
When `prefetch_primary_key?` returns `true` insert statement
always have the primary key name since the primary key value is selected
from the associated sequence. However, supporting identity data type
will make `prefetch_primary_key?` returns `false`
then no primary key column name added.
As a result, `empty_insert_statement_value` raises `NotImplementedError`
To address this error `empty_insert_statement_value` can take
one argument `primary_key` to generate insert statement like this.
`INSERT INTO "POSTS" ("ID") VALUES(DEFAULT)`
It needs arity change for the public method but no actual behavior changes for the bundled adapters.
Oracle enhanced adapter `empty_insert_statement_value` implementation will be like this:
```
def empty_insert_statement_value(primary_key)
raise NotImplementedError unless primary_key
"(#{quote_column_name(primary_key)}) VALUES(DEFAULT)"
end
```
[Raise NotImplementedError when using empty_insert_statement_value with Oracle](https://github.com/rails/rails/pull/28029)
[Add support for INSERT .. DEFAULT VALUES](https://community.oracle.com/ideas/13845)
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Return back "/" to the end of RAILS_GEM_ROOT
|
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- The "/" was removed in 40bdbce191ad90dfea43dad51fac5c4726b89392 during
refactoring. It may cause regression since looks like was added
intentionaly because it is possible that a name of any another gem
can start with /rails/, so slash was added to ensure that it is "rails"
gem.
I would like to backport this to `5-2-stable` too.
- Use `__dir__` instead of `__FILE__`. Follow up #29176.
|
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The extracted method is used for `CollectionCacheAssociationLoading`,
still not public API.
[ci skip]
|
|/ / / / |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This was added in 280587588aba6ce13717cd6679e3f2b43d287443, but has been
unused since 392eeecc11a291e406db927a18b75f41b2658253.
|
| | | | |
|
|/ / /
| | |
| | |
| | |
| | | |
This commit fixes all references in the codebase missing a trailing :,
which causes the nodoc not to actually work :) [skip ci]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ok so apparently you can not just have a `default:` that manually is
merged in with YAML but you can also have a special "shared" config that
is automatically merged.
Example:
```
shared:
adapter: mysql2
host: <%= ENV["DB_HOST"] || "localhost" %>
username: root
connect_timeout: 0
pool: 100
reconnect: true
development:
database: development_db
adapter: mysql2
```
To fix, only create a DatabaseConfig object when an adapter, database,
or URL are present.
The merging behavior for `shared` doesn't work with a 3-tier config. I
don't think it worked before this change either - since Rails doesn't
know which point to merge it in. That's something we may have to fix
with the refactoring I'm working on.
|