| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
An entry in `ActiveRecord::Base.configurations` can either be a
connection spec ("two-level") or a hash of specs ("three-level").
We were detecting two-level configurations by looking for the `database`
key, but the database can also be specified as part of the `url` key,
which meant we incorrectly treated those configurations as three-level.
|
|
|
|
| |
https://travis-ci.org/rails/rails/jobs/360109429
|
|\
| |
| | |
Don't unset foreign key when preloading missing record
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a belongs to association's target is set, its foreign key is now
updated to match the new target. This is the correct behaviour when a
new record is assigned, but not when the existing record is preloaded.
As long as we mark the association as loaded, we can skip setting the
target when the record is missing and avoid clobbering the foreign key.
|
| |
| |
| |
| | |
Fix deprecation warnings from with_lock
|
|\ \
| | |
| | | |
Expose foreign key name ignore pattern in configuration
|
| | |
| | |
| | |
| | |
| | | |
This makes more sense, as the foreign key ignore pattern is only used by
the schema dumper.
|
| | | |
|
|\ \ \
| |_|/
|/| | |
Part 1 Easy Multi db in Rails: Add basic rake tasks for multi db setup
|
| |/ |
|
|\ \
| | |
| | | |
Add custom prefix to ActiveRecord::Store accessors
|
| | |
| | |
| | |
| | |
| | |
| | | |
Add a prefix option to ActiveRecord::Store.store_accessor and
ActiveRecord::Store.store. This option allows stores to have identical keys
with different accessors.
|
|/ /
| |
| |
| |
| |
| |
| | |
The multiple assignments was caused by 37a1dfa due to lost the `to_s`
normalization for given names.
Fixes #32323.
|
|/
|
|
|
| |
It makes to ease to detect a future regression as long as the methods
are covered by this test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test fails in specific time.
Example:
If run this test on the machine with time 01:00 am UTC+2,
this test will fail.
Changing representing of 2000-01-01 01:00 am UTC+2 to UTC+0 change
the day, month and even year in our case,
so substitution `"2000-01-01 "` to `""` isn't possible.
```
Failure:
ActiveRecord::ConnectionAdapters::QuotingTest#test_quoted_time_utc
Expected: "1999-12-31 23:01:27"
Actual: "23:01:27"
```
Related to 7c479cbf
|
|\
| |
| | |
Fix default connection handling with three-tier config
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If you had a three-tier config, the `establish_connection` that's called
in the Railtie on load can't figure out how to access the default
configuration.
This is because Rails assumes that the config is the first value in the
hash and always associated with the key from the environment. With a
three tier config however we need to go one level deeper.
This commit includes 2 changes. 1) removes a line from `resolve_all`
which was parsing out the the environment from the config so instead of
getting
```
{
:development => {
:primary => {
:database => "whatever"
}
},
:animals => {
:database => "whatever-animals"
}
},
etc with test / prod
}
```
We'd instead end up with a config that had no attachment to it's
envioronment.
```
{
:primary => {
:database => "whatever"
}
:animals => {
:database => "whatever-animals"
}
etc - without test and prod
}
```
Not only did this mean that Active Record didn't know how to establish a
connection, it didn't have the other necessary configs along with it in
the configs list.
So fix this I removed the line that deletes these configs.
The second thing this commit changes is adding this line to
`establish_connection`
```
spec = spec[spec_name.to_sym] if spec[spec_name.to_sym]
```
When you have a three-tier config and don't pass any hash/symbol/env etc
to `establish_connection` the resolver will automatically return both
the primary and secondary (in this case animals db) configurations.
We'll get an `database configuration does not specify adapter` error
because AR will try to establish a connection on the `primary` key
rather than the `primary` key's config. It assumes that the
`development` or default env automatically will return a config hash,
but with a three-tier config we actually get a key and config `primary
=> config`.
This fix is a bit of a bandaid because it's not the "correct" way to
handle this situation, but it does solve our immediate problem. The new
code here is saying "if the config returned from the resolver (I know
it's called spec in here but we interchange our meanings a LOT and what
is returned is a three-tier config) has a key matching the "primary"
spec name, grab the config from the spec and pass that to the
estalbish_connection method".
This works because if we pass `:animals` or a hash, or `:primary` we'll
already have the correct configuration to connect with.
This fixes the case where we want Rail to connect with the default
connection.
Coming soon is a refactoring that should eliminate the need to do this
but I need this fix in order to write the multi-db rake tasks that I
promised in my RailsConf submission. `@tenderlove` and I are working on
the refactoring of the internals for connection management but it won't
be ready for a few weeks and this issue has been blocking progress.
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
lsylvester/only-preload-misses-on-multifetch-cache
Only preload misses on multifetch cache
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In #24542, quoted_time was introduced to strip the leading date
component for time columns because it was having a significant
effect in mariadb. However, it assumed that the date component
was always 2000-01-01 which isn't the case, especially if the
source wasn't another time column.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For legacy reasons Rails stores time columns on sqlite as full
timestamp strings. However because the date component wasn't being
normalized this meant that when they were read back they were being
prefixed with 2001-01-01 by ActiveModel::Type::Time. This had a
twofold result - first it meant that the fast code path wasn't being
used because the string was invalid and second it was corrupting the
second fractional component being read by the Date._parse code path.
Fix this by a combination of normalizing the timestamps on writing
and also changing Active Model to be more lenient when detecting
whether a string starts with a date component before creating the
dummy time value for parsing.
|
| |/
|/|
| |
| |
| |
| |
| | |
In #20317, datetime columns had their precision applied on assignment but
that behaviour wasn't applied to time columns - this commit fixes that.
Fixes #30301.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a class has a belongs_to or has_one relationship with dependent: :destroy
option enabled, objects of this class should not be deleted if it's dependents
cannot be deleted.
Example:
class Parent
has_one :child, dependent: :destroy
end
class Child
belongs_to :parent, inverse_of: :child
before_destroy { throw :abort }
end
c = Child.create
p = Parent.create(child: c)
p.destroy
p.destroyed? # expected: false; actual: true;
Fixes #32022
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locking is enabled
This issue is caused by `@_trigger_update_callback` won't be updated due
to `_update_record` in `Locking::Optimistic` doesn't call `super` when
optimistic locking is enabled.
Now optimistic locking concern when updating is supported by
`_update_row` low level API, therefore overriding `_update_record` is no
longer necessary.
Removing the method just fix the issue.
Closes #29096.
Closes #29321.
Closes #30823.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently primary key value can not be updated if a record has a locking
column because of `_update_record` in `Locking::Optimistic` doesn't
respect `id_in_database` as primary key value unlike in `Persistence`.
And also, if a record has dirty primary key value, it may destroy any
other record by the lock version of dirty record itself.
When updating/destroying persisted records, it should identify
themselves by `id_in_database`, not by dirty primary key value.
|
|
|
|
| |
Related to https://github.com/rails/rails/commit/d4eb0dc89ee6b476e2e10869dc282a96f956c6c7#r27830891
|
|
|
|
|
|
|
|
|
|
| |
This reverts ignoring polymorphic error introduced at 02da8ae.
What the ignoring want to solve was caused by force eager loading
regardless of whether it is necessary, but it has been fixed by #29043.
The ignoring is now only causing a mismatch of `exists?` behavior with
`to_a`, `count`, etc. It should behave consistently.
|
|
|
|
|
|
|
| |
This is an alternative of #29722, and follow up of #32048.
This does not change the current behavior, but makes it easier to modify
all polymorphic names consistently.
|
|
|
|
| |
Since Rails 6 requires Ruby 2.4.1+.
|
|
|
|
| |
Related to 948b931925febac3c965ab13470065ced68f7b53
|
|
|
|
|
|
|
| |
Prevent `ActiveRecord::FinderMethods#limited_ids_for` from using correct primary
key values even if `ORDER BY` columns include other table's primary key.
Fixes #28364.
|
|\
| |
| |
| | |
Active Record distinct & order #count regression
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
tgxworld/raise_error_when_advisory_lock_is_not_releases
Raise an error if advisory lock in migrator was not released.
|
| | | |
|
| | |
| | |
| | |
| | | |
See 948b931925febac3c965ab13470065ced68f7b53 for context
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently the place where we limit what gets sent to the database is in
the implementation for `partial_writes`. We should also be restricting
it to column names when partial writes are turned off.
Note that we're using `&` instead of just defaulting to
`self.class.column_names`, as the instance version of `attribute_names`
does not include attributes which are uninitialized (were not included
in the select clause)
|
| |/
|/|
| |
| |
| |
| |
| |
| | |
Since #31895, build of 2.5 and AR combination failed.
https://travis-ci.org/rails/rails/jobs/346064349#L1638
It seems to be the reason that model is not loading properly, so I added
require. But I'm not sure if this is correct
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/do_not_attempt_to_find_inverse_of_polymorphic
Make `reflection.klass` raise if `polymorphic?` not to be misused
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is an alternative of #31877 to fix #31876 caused by #28808.
This issue was caused by a combination of several loose implementation.
* finding automatic inverse association of polymorphic without context (caused by #28808)
* returning `klass` even if `polymorphic?` (exists before #28808)
* loose verification by `valid_inverse_reflection?` (exists before #28808)
This makes `klass` raise if `polymorphic?` not to be misused.
This issue will not happen unless polymorphic `klass` is misused.
Fixes #31876.
Closes #31877.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is an alternative of #29722, and revert of #29601 and a1fcbd9.
Currently, association creation and normal association finding doesn't
respect `store_full_sti_class`. But eager loading and preloading respect
the setting. This means that if set `store_full_sti_class = false`
(`true` by default), eager loading and preloading can not find
created polymorphic records.
Association creation and finding should work consistently.
|
| | |
| | |
| | |
| | |
| | | |
* Add test case for open-ended range.
* Add test case for numeric range for string column.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
BC dates are supported by both date and datetime types.
https://www.postgresql.org/docs/current/static/datatype-datetime.html
Since #1097, new datetime allows year zero as 1 BC, but new date does
not. It should be allowed even in new date consistently.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The values infinity and -infinity are supported by both date and
timestamp types.
https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-SPECIAL-TABLE
And also, it can not be known whether a value is infinity correctly
unless cast a value.
I've added `QueryAttribute#infinity?` to handle that case.
Closes #27585.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 16f279ebd474626577ced858e3626ac4535a33df, reversing
changes made to 6c6a30a7c357ce1eafa093d77d2b08684fe50887.
The config can be named anything, not just default (although all
generated apps will be named default). We can't just delete configs that
don't have a database because that will break three-tier configs. Oh
well.
|