| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Fix default value for mysql time types with specified precision
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TIME, DATETIME, and TIMESTAMP types [have supported](https://mariadb.com/kb/en/library/microseconds-in-mariadb/)
a fractional seconds precision from 0 to 6.
Default values from time columns with specified precision is read
as `current_timestamp(n)` from information schema.
rake `db:schema:dump` produces `schema.rb` **without** default values for time columns with the specified precision:
t.datetime "last_message_at", precision: 6, null: false
rake `db:schema:dump` produces `schema.rb` **with** default values for time columns with the specified precision:
t.datetime "last_message_at", precision: 6, default: -> { "current_timestamp(6)" }, null: false
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the seen object cache is shared if join nodes have the same
target class. But it is a wrong assumption, we can't share the seen
object cache between different join nodes (e.g. `:readonly_account` and
`:accounts` have the same target class `Account`, but the instances
have the different state `readonly`).
Fixes #26805.
Closes #27737.
|
|\
| |
| |
| | |
Support readonly option in SQLite3Adapter
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Readonly sqlite database files are very useful as a data format for
storing configuration/lookup data that is too complicated for YAML
files. But since such files would typically be committed to a source
control repository, it's important to ensure that they are truly safe
from being inadvertently modified. Unfortunately using unix permissions
isn't enough, as sqlite will "helpfully" add the write bit to a database
file whenever it's written to.
sqlite3-ruby has supported a `:readonly` option since version 1.3.2 (see
https://github.com/sparklemotion/sqlite3-ruby/commit/c20c9f5dd2990042)
This simply passes that option through to the adapter if present in the
config hash. I think this is best considered an adapter-specific option
since no other supported database has an identical concept.
|
| |
|
|
|
|
|
| |
Now that `allocate` is removed, we need to define attribute methods in
all "init" methods.
|
|\
| |
| |
| |
| |
| |
| |
| | |
* master:
Call initialize after allocate
Remove `ActiveSupport::Concern` from `ActiveRecord::Aggregations`
Add example for no_touching? in active_record/no_touching for api docs [ci skip]
Generate a new key for each service test
|
| |
| |
| |
| |
| |
| |
| |
| | |
If someone calls allocate on the object, they'd better also call an
initialization routine too (you can't expect allocate to do any
initialization work). Before this commit, AR objects that are
instantiated from the database would call `define_attribute_methods`
twice.
|
| |
| |
| |
| |
| | |
`include Aggregations` no longer needs to invoke
`extend Aggregations::ClassMethods` since 657060b.
|
| |
| |
| |
| |
| | |
There was no example code for ActiveRecord::NoTouching#no_touching?.
This PR adds an example for the API docs.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit speeds up allocating homogeneous lists of AR objects. We
can know if the result set contains an STI column before initializing
every AR object, so this change pulls the "does this result set contain
an STI column?" test up, then uses a specialized instantiation function.
This way we only have to check for an STI column once rather than N
times.
This change also introduces a new initialization function that is meant
for use when allocating AR objects that come from the database. Doing
this allows us to eliminate one hash allocation per AR instance.
Here is a benchmark:
```ruby
require 'active_record'
require 'benchmark/ips'
ActiveRecord::Base.establish_connection adapter: "sqlite3", database: ":memory:"
ActiveRecord::Migration.verbose = false
ActiveRecord::Schema.define do
create_table :users, force: true do |t|
t.string :name
t.timestamps null: false
end
end
class User < ActiveRecord::Base; end
2000.times do
User.create!(name: "Gorby")
end
Benchmark.ips do |x|
x.report("find") do
User.limit(2000).to_a
end
end
```
Results:
Before:
```
[aaron@TC activerecord (master)]$ be ruby -I lib:~/git/allocation_tracer/lib speed.rb
Warming up --------------------------------------
find 5.000 i/100ms
Calculating -------------------------------------
find 56.192 (± 3.6%) i/s - 285.000 in 5.080940s
```
After:
```
[aaron@TC activerecord (homogeneous-allocation)]$ be ruby -I lib:~/git/allocation_tracer/lib speed.rb
Warming up --------------------------------------
find 7.000 i/100ms
Calculating -------------------------------------
find 72.204 (± 2.8%) i/s - 364.000 in 5.044592s
```
|
|
|
|
|
|
|
|
| |
`composed_of` is a fairly rare method to call on models. This commit
adds the `Aggregations` module to models that call `composed_of` so that
models that *don't* call `composed_of` don't need to instantiate the
`aggregation_cache` hash. This saves one hash allocation per model
instance that doesn't use `composed_of`
|
|
|
|
| |
hash condition
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "join" affix in `table_alias_for` was added 12 years ago at 02d3444
to address poor alias tracking.
`AssociationScope` no longer uses the "join" suffixed alias since
0408e21 and had been removed at a1ec8b5.
`table_alias_for` is the last place that using the useless legacy
suffixed alias, but we can't remove the suffix since some test cases
directly refers the alias name by `where` with string literal, so at
least removing the suffix would break our test cases.
(e.g. https://github.com/rails/rails/blob/b2eb1d1c55a59fee1e6c4cba7030d8ceb524267c/activerecord/test/cases/associations/has_and_belongs_to_many_associations_test.rb#L699-L731).
|
| |
|
|
|
|
| |
[Jon Moss & Xavier Noria]
|
| |
|
|
|
|
| |
Follow up of 15367a2c674bf19eeefa12ccb64391bdd50d883d.
|
|
|
|
|
| |
Since `aliases` is a part of `JoinDependency` and already cached at
1a723c65bbe91ad969b67416233d20eff6d2a46a.
|
|
|
|
| |
It was no longer used since d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734.
|
|\
| |
| | |
Reduce Memory Allocation when using .pluck
|
| |
| |
| |
| | |
to speed up pluck
|
|\ \
| | |
| | | |
Removed useless utility classes inside HABTM association builder
|
| |/ |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, column aliases which is used for eager loading are calculated
before constructing all table aliases in FROM clause.
`JoinDependency#join_constraints` constructs table aliases for `joins`
first, and then always re-constructs table aliases for eager loading.
If both `joins` and eager loading are given a same table association,
the re-construction would cause the discrepancy between column aliases
and table aliases.
To avoid the discrepancy, the column aliases should be calculated after
all table aliases are constructed.
Fixes #30603.
|
|\
| |
| | |
Add docs for ActiveRecord::Migration#say, #say_with_time, #suppress_messages [ci skip]
|
| |
| |
| |
| | |
[ci skip]
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`touch` option was added to `increment!` (#27660) and `update_counters`
(#26995). But that option behaves inconsistently with
`Persistence#touch` method.
If `touch` option is passed attribute names, it won't update
update_at/on attributes unlike `Persistence#touch` method.
Due to changed from `Persistence#touch` to `increment!` with `touch`
option, #31405 has a regression that `counter_cache` with `touch` option
which is passed attribute names won't update update_at/on attributes.
I think that the inconsistency is not intended. To get back consistency,
ensure that `touch` option updates update_at/on attributes.
|
|\
| |
| |
| | |
Allow prefix/suffix options for store accessors
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This may seem like an unnecessary refactoring but some apps want / need
to configure the information passed to the query cache logger. In order
to do that we can add a method here that can be easily overridden by the
app itself, rather than hacking the query cache logger to include that
information.
To override apps can call
```
def cache_notifications_info
super.merge(connected_host: "hostname")
end
```
This will take what's already in the query cache logger and add
`@something="yea"` to the object.
At GitHub we use this to log the number of queries that are cached, the
connection host and the connection url.
|
| |
| |
| |
| |
| | |
It mark the association as loaded and this can cause the object to be in
an stale state.
|
| |
| |
| |
| |
| | |
This also mark the association as loaded given we changed it in memory
and avoid the next access to the reader to make a query to the databse.
|
|\ \
| | |
| | |
| | | |
Use hash lookup for deleting existing associations from `target`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`Array#delete` searches for all occurrences in the `target` array. When performing `dependent: :destroy` in active_record/associations/collection_association, the loop becomes O(N^2). It is particularly slow when destroying large amount of associations (e.g. 10K records).
Either `Hash` or `Set` can optimize the loop to O(N). `Hash` is slightly faster in this simple usage.
```ruby
class Dummy; end
num = 10_000
test1a = num.times.map { Dummy.new }; nil
test1b = test1a.dup
test2a = num.times.map { Dummy.new }; nil
test2b = test2a.dup
Benchmark.ips do |x|
x.config(stats: :bootstrap, confidence: 95)
x.report("hash") do
hash = test1a.group_by { |r| r }
test1b.select! { |r| !hash[r] }
end
x.report("array") do
test2a.each { |r| test2b.delete(r) }
end
x.compare!
end
```
```
Calculating -------------------------------------
hash 11.000 i/100ms
array 1.000 i/100ms
-------------------------------------------------
hash 114.586 (±16.6%) i/s - 561.000
array 1.710k (±10.3%) i/s - 8.377k
Comparison:
array: 1710.4 i/s
hash: 114.6 i/s - 14.93x slower
```
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
left_joins
This regression was caused by #30995 due to `Hash#fetch` won't invoke
default proc. Just revert the change since #30995 is completely fixed by
e9c1653.
Fixes #33048.
|
| | |
| | |
| | |
| | | |
[ci skip]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If `eager_loading` is true, `apply_join_dependency` force applies
LIMIT/OFFSET before JOINs by `limited_ids_for` to keep parent records
count. But for aggregation queries, LIMIT/OFFSET should be applied after
aggregations the same as SQL semantics.
And also, we could not replace SELECT list by `limited_ids_for` when a
query has a GROUP BY clause. It had never been worked since it will
causes generating invalid SQL for MySQL, PostgreSQL, and probably most
backends.
```
% ARCONN=postgresql be ruby -w -Itest test/cases/calculations_test.rb -n test_group_by_with_limit
Using postgresql
Run options: -n test_group_by_with_limit --seed 20925
# Running:
E
Error:
CalculationsTest#test_group_by_with_limit:
ActiveRecord::StatementInvalid: PG::GroupingError: ERROR: column "posts.id" must appear in the GROUP BY clause or be used in an aggregate function
LINE 1: SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FRO... ^
: SELECT DISTINCT "posts"."id", "posts"."type" AS alias_0 FROM "posts" LEFT OUTER JOIN "comments" ON "comments"."post_id" = "posts"."id" GROUP BY "posts"."type" ORDER BY "posts"."type" ASC LIMIT $1
```
Fixes #8103.
Closes #27249.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In `_create_record`, explicit `transaction` block requires rollback
handling manually when `insert_record` is failed.
We need to handle it in `_create_record`, not in `insert_record`, since
our test cases expect a record added to target and returned even if
`insert_record` is failed,
Closes #31488.
|
| | |
| | |
| | |
| | | |
Follow up of #32952.
|
|\ \ \
| | | |
| | | | |
Fix force equality checking not to break the serialized attribute with Array
|
| | | |
| | | |
| | | |
| | | | |
Context: https://github.com/rails/rails/commit/43ef00e5d7a55ad79bc840276d33cb70f1f5dde5#commitcomment-29256140
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rails 5.2 does not alias child joins, causing an error about duplicated table/fields:
Example:
Using some code like:
`Post.joins(:author, :categorizations).merge(Author.select(:id)).merge(Categorization.joins(:author))`
*Before this fix:*
`
SELECT ... FROM "posts" INNER JOIN "authors" ON ... INNER JOIN "authors" ON ...
`
*After this fix:*
`
SELECT ... FROM "posts" INNER JOIN "authors" ON ... INNER JOIN "authors" "authors_categorizations" ON ...
`
Before 5.2, Rails aliased the joins, but wrongfully transformed them into a LEFT OUTER JOIN.
This fix will keep them as INNER JOINS, but make sure child joins are aliased, to avoid errors.
|
|\ \ \
| | | |
| | | | |
PERF: avoid allocating column names where possible
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When requesting columns names from database adapters AR:Result
would dup/freeze column names, this prefers using fstrings which
cuts down on repeat allocations
Attributes that are retained keep these fstrings around for the long
term
Note, this has the highest impact on "short" result sets, eg: Topic.first where you can void allocating the number of columns * String.
|
|\ \ \ \
| | | | |
| | | | | |
Migrations will raise an exception if there are multiple column defin…
|
| |/ / /
| | | |
| | | |
| | | | |
(same name).
|