| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Also remove `# :nodoc:` for `ActiveRecord::Core::ClassMethods` in order
to show non-nodoc methods in that module on the api docs http://edgeapi.rubyonrails.org
|
|
|
|
|
|
|
|
|
| |
It would allow `filter_attributes` to be reused across multiple
calls to `#inspect` or `#pretty_print`.
- Add `require "set"`
- Remove `filter_attributes` instance reader. I think there is no need
to keep it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Move
```
filter_attributes = self.filter_attributes.map(&:to_s).to_set
filter_attributes.include?(attribute_name) && !read_attribute(attribute_name).nil?
```
to private method.
- Fix tests in `activerecord/test/cases/filter_attributes_test.rb`
- Ensure that `teardown` sets `ActiveRecord::Base.filter_attributes` to
previous state.
- Ensure that `Admin::Account.filter_attributes` is set to previous
state in the "filter_attributes could be overwritten by models" test.
Follow up #33756
|
|
|
|
|
| |
Add mention that `config.filter_parameters` also filters out sensitive
values of database columns when call `#inspect` since #33756.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sensitive value of database column when call `#inspect`
* Why
Some sensitive data will be exposed in log accidentally by calling `#inspect`, e.g.
```ruby
@account = Account.find params[:id]
payload = { account: @account }
logger.info "payload will be #{ payload }"
```
All the information of `@account` will be exposed in log.
* Solution
Add a class attribute filter_attributes to specify which values of columns shouldn't be exposed.
This attribute equals to `Rails.application.config.filter_parameters` by default.
```ruby
Rails.application.config.filter_parameters += [:credit_card_number]
Account.last.insepct # => #<Account id: 123, credit_card_number: [FILTERED] ...>
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
|
|
|
|
|
| |
This commit follows the path we started at commit #ea4f0e2
and continued at PR #33229.
|
|
|
|
|
| |
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.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the time the table and predicate_builder
passed to Relation.new are exactly the
arel_table and predicate builder of the
given klass. This uses klass.arel_table
and klass.predicate_builder as the defaults,
so we don't have to pass them in most cases.
This does change the signaure of both Relation and
AssocationRelation. Are we ok with that?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new ActiveRecord configuration option allows you to easily
pinpoint what line of application code is triggering SQL queries in the
development log by appending below each SQL statement log the line of
Ruby code that triggered it.
It’s useful with N+1 issues, and to locate stray queries.
By default this new option ignores Rails and Ruby code in order to
surface only callers from your application Ruby code or your gems.
It is enabled on newly generated Rails 5.2 applications and can be
enabled on existing Rails applications:
```ruby
Rails.application.configure do
# ...
config.active_record.verbose_query_logs = true
end
```
The `rails app:upgrade` task will also add it to
`config/development.rb`.
This feature purposely avoids coupling with
ActiveSupport::BacktraceCleaner since ActiveRecord can be used without
ActiveRecord. This decision can be reverted in the future to allow more
configurable backtraces (the exclusion of gem callers for example).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These extra `spawn` are called via `klass.all` and `klass.all` is called
everywhere in the internal. Avoiding the extra `spawn` makes` klass.all`
30% faster for STI classes.
https://gist.github.com/kamipo/684d03817a8115848cec8e8b079560b7
```
Warming up --------------------------------------
fast relation 4.410k i/100ms
slow relation 3.334k i/100ms
Calculating -------------------------------------
fast relation 47.373k (± 5.2%) i/s - 238.140k in 5.041836s
slow relation 35.757k (±15.9%) i/s - 176.702k in 5.104625s
Comparison:
fast relation: 47373.2 i/s
slow relation: 35756.7 i/s - 1.32x slower
```
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comment was added at 97849de, but `AssociationProxy` and
`test_triple_equality` was removed at 1644663. Currently the `===` is
used for `test_decorated_polymorphic_where` that added at #11945.
So I updated "association proxies" to "decorated models".
And also, currently `Core::ClassMethods` appears in the doc.
http://api.rubyonrails.org/classes/ActiveRecord/Core/ClassMethods.html
But it looks like that the methods in the module is not public API.
So I also added `# :nodoc:` to the module.
|
|
|
|
|
| |
Statement caches are used as a concurrent map. It will more clarify to
using `Concurrent::Map`.
|
|
|
|
|
|
| |
Actually `StatementCache#execute` is always passed the same klass that
the owner klass of the connection when the statement cache is created.
So passing `klass` to `StatementCache.new` will make more DRY.
|
|\
| |
| | |
Fix `find_by` with range conditions
|
| |
| |
| |
| |
| | |
`StatementCache` doesn't support range conditions. So we need to through
the args to `FinderMethods#find_by` if range value is passed.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
`arel_engine` is only used in `raise_record_not_found_exception!` to use
`engine.connection` (and `connection.visitor`) in `arel.where_sql`.
https://github.com/rails/arel/blob/v8.0.0/lib/arel/select_manager.rb#L183
But `klass.connection` will work as expected even if not using
`arel_engine` (described by `test_connection`). So `arel_engine` is no
longer needed.
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
| |
|
|
|
|
|
|
| |
This was added in c24c885209ac2334dc6f798c394a821ee270bec6, removed in
b89ffe7f0047eb614e42232a21201b317b880755, and then (unintentionally?)
reintroduced in 2d7ae1b08ee2a10b12cbfeef3a6cc6da55b57df6.
|
|
|
|
|
|
|
|
|
|
| |
`scope_for_create`
`type_condition` should be overwritten by `create_with_value`. So `type`
in `create_with_value` should be a string because `where_values_hash`
keys are converted to string.
Fixes #27600.
|
|
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
|
|
|
|
|
|
|
|
|
| |
The alternative of #26213.
Currently `find_by` and `where` with AR object return inconsistent
result. This is caused by statement cache does not support AR object.
Passing to finder method to fix the issue.
Fixes #26210.
|
|
|
|
| |
find and exists?
|
|
|
|
|
|
|
|
|
|
|
|
| |
- After https://github.com/rails/rails/commit/64e5b897ac944a05a33275e3828a3d4047a6b457,
only :GeneratedAssociationMethods was remaining to be marked as
private constant, so marked it as well.
- Before:
>> User.constants(false)
=> [:GeneratedAssociationMethods]
- After:
>> User.constants(false)
=> []
|
| |
|
|
|
|
| |
Raise `ActiveRecord::RangeError` when values that executed are out of range.
|
|
|
|
|
|
|
|
| |
If the call to `.define_attribute_methods` actually ends up loading the
schema (*very* hard to do, as it requires the object being created
without `allocate` having been called, but it can be done by manually
calling `initialize` from inside `marshal_load` if you're crazy), the
value of `_default_attributes` will change from that call.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This is not as good a solution as actually hashing both values, but Ruby
doesn't expose that capability other than allocating the array. Unless we were
to do something silly like have a thread local array that is re-used, I don't
see any other way to do this without allocation. This solution may not be
perfect, but it should reasonably avoid collisions to the extent that we need.
|
| |
|
|
|
|
| |
The fact that this only includes column names is an oversight.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.
For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.
Fixes #26320.
|
|
|
|
| |
Rails dropped Ruby 1.9 support, but this comment still true.
|
| |
|
|
|
|
|
|
|
|
|
| |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
|
|
|
| |
Some case expressions remain, need to think about those ones.
|
| |
|