aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/core.rb
Commit message (Collapse)AuthorAgeFilesLines
* Fixed a typo in documentation example of activerecord database ↵Akshay Mohite2019-08-011-1/+1
| | | | | | configuration. [ci skip] - The example has sqlite3 adpater in database.yml, whereas configuration object had incorrectly specified mysql2 in documentation.
* Enable `Layout/EmptyLinesAroundAccessModifier` copRyuta Kamizono2019-06-131-2/+0
| | | | | | | | | | | We sometimes say "✂️ newline after `private`" in a code review (e.g. https://github.com/rails/rails/pull/18546#discussion_r23188776, https://github.com/rails/rails/pull/34832#discussion_r244847195). Now `Layout/EmptyLinesAroundAccessModifier` cop have new enforced style `EnforcedStyle: only_before` (https://github.com/rubocop-hq/rubocop/pull/7059). That cop and enforced style will reduce the our code review cost.
* Avoid redundant `attribute_alias?` before `attribute_alias`Ryuta Kamizono2019-04-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we want to get alias resolved attribute finally, we can use `attribute_alias` directly. For that purpose, avoiding redundant `attribute_alias?` makes alias attribute access 40% faster. https://gist.github.com/kamipo/e427f080a27b46f50bc508fae3612a0e Before (2c0729d8): ``` Warming up -------------------------------------- user['id'] 102.668k i/100ms user['new_id'] 80.660k i/100ms user['name'] 99.368k i/100ms user['new_name'] 81.626k i/100ms Calculating ------------------------------------- user['id'] 1.431M (± 4.0%) i/s - 7.187M in 5.031985s user['new_id'] 1.042M (± 4.2%) i/s - 5.243M in 5.039858s user['name'] 1.406M (± 5.6%) i/s - 7.055M in 5.036743s user['new_name'] 1.074M (± 3.6%) i/s - 5.387M in 5.024152s ``` After (this change): ``` Warming up -------------------------------------- user['id'] 109.775k i/100ms user['new_id'] 103.303k i/100ms user['name'] 105.988k i/100ms user['new_name'] 99.618k i/100ms Calculating ------------------------------------- user['id'] 1.520M (± 6.7%) i/s - 7.574M in 5.011496s user['new_id'] 1.485M (± 6.2%) i/s - 7.438M in 5.036252s user['name'] 1.538M (± 5.4%) i/s - 7.737M in 5.049765s user['new_name'] 1.516M (± 4.6%) i/s - 7.571M in 5.007293s ```
* Re-organize `init_internals`Ryuta Kamizono2019-04-241-5/+4
| | | | | * Avoid duplicated `@new_record` assignment * Extract `define_attribute_methods` into `init_internals`
* Lazy allocate `@_start_transaction_state`Ryuta Kamizono2019-04-241-2/+2
|
* PERF: 20% faster pk attribute accessRyuta Kamizono2019-04-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've realized that `user.id` is 20% slower than `user.name` in the benchmark (https://github.com/rails/rails/pull/35987#issuecomment-483882480). The reason that performance difference is that `self.class.primary_key` method call is a bit slow. Avoiding that method call will make almost attribute access faster and `user.id` will be completely the same performance with `user.name`. Before (02b5b8cb): ``` Warming up -------------------------------------- user.id 140.535k i/100ms user['id'] 96.549k i/100ms user.name 158.110k i/100ms user['name'] 94.507k i/100ms user.changed? 19.003k i/100ms user.saved_changes? 25.404k i/100ms Calculating ------------------------------------- user.id 2.231M (± 0.9%) i/s - 11.243M in 5.040066s user['id'] 1.310M (± 1.3%) i/s - 6.565M in 5.012607s user.name 2.683M (± 1.2%) i/s - 13.439M in 5.009392s user['name'] 1.322M (± 0.9%) i/s - 6.615M in 5.003239s user.changed? 201.999k (±10.9%) i/s - 1.007M in 5.091195s user.saved_changes? 258.214k (±17.1%) i/s - 1.245M in 5.007421s ``` After (this change): ``` Warming up -------------------------------------- user.id 158.364k i/100ms user['id'] 106.412k i/100ms user.name 158.644k i/100ms user['name'] 107.518k i/100ms user.changed? 19.082k i/100ms user.saved_changes? 24.886k i/100ms Calculating ------------------------------------- user.id 2.768M (± 1.1%) i/s - 13.936M in 5.034957s user['id'] 1.507M (± 2.1%) i/s - 7.555M in 5.017211s user.name 2.727M (± 1.5%) i/s - 13.643M in 5.004766s user['name'] 1.521M (± 1.3%) i/s - 7.634M in 5.018321s user.changed? 200.865k (±11.1%) i/s - 992.264k in 5.044868s user.saved_changes? 269.652k (±10.5%) i/s - 1.344M in 5.077972s ```
* Remove never used `database_selector` class accessorRyuta Kamizono2019-04-221-1/+0
| | | | It was never used from the beginning.
* Avoid method call if `@transaction_state` is not finalizedRyuta Kamizono2019-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Method call in Ruby is a bit slow. This makes attribute access 10% faster by avoiding method call (`sync_with_transaction_state`). Before (96cf7e0e): ``` Warming up -------------------------------------- user.id 131.291k i/100ms user['id'] 91.786k i/100ms user.name 151.605k i/100ms user['name'] 92.664k i/100ms user.changed? 17.772k i/100ms user.saved_changes? 23.909k i/100ms Calculating ------------------------------------- user.id 1.988M (± 7.0%) i/s - 9.978M in 5.051474s user['id'] 1.155M (± 5.8%) i/s - 5.783M in 5.022672s user.name 2.450M (± 4.3%) i/s - 12.280M in 5.021234s user['name'] 1.263M (± 2.1%) i/s - 6.394M in 5.066638s user.changed? 175.070k (±13.3%) i/s - 853.056k in 5.011555s user.saved_changes? 259.114k (±11.8%) i/s - 1.267M in 5.001260s ``` After (this change): ``` Warming up -------------------------------------- user.id 137.625k i/100ms user['id'] 96.054k i/100ms user.name 156.379k i/100ms user['name'] 94.795k i/100ms user.changed? 18.172k i/100ms user.saved_changes? 24.337k i/100ms Calculating ------------------------------------- user.id 2.201M (± 0.5%) i/s - 11.010M in 5.002955s user['id'] 1.320M (± 1.0%) i/s - 6.628M in 5.021293s user.name 2.677M (± 1.6%) i/s - 13.449M in 5.024399s user['name'] 1.314M (± 1.8%) i/s - 6.636M in 5.051444s user.changed? 190.588k (±11.1%) i/s - 944.944k in 5.065848s user.saved_changes? 262.782k (±12.1%) i/s - 1.290M in 5.028080s ```
* Fix dirty tracking after rollback.Ryuta Kamizono2019-04-161-6/+0
| | | | | | | | | | | | | | | | | Currently the rollback only restores primary key value, `new_record?`, `destroyed?`, and `frozen?`. Since the `save` clears current dirty attribute states, retrying save after rollback will causes no change saved if partial writes is enabled (by default). This makes `remember_transaction_record_state` remembers original values then restores dirty attribute states after rollback. Fixes #15018. Fixes #30167. Fixes #33868. Fixes #33443. Closes #33444. Closes #34504.
* Lazy sync with transaction state on destroyRyuta Kamizono2019-04-101-1/+2
| | | | | | | | | | | | | | | | This reverts commit 58410b3d566e6b93c7b71c0eec0fc11ec906b68e. If we have any implicit commit/rollback callbacks, it is necessary to add record to transaction explicitly like `:touch_deferred_attributes`. https://github.com/rails/rails/blob/5f261d04d6f857d49c75124df809adfbd6cd5b5e/activerecord/lib/active_record/touch_later.rb#L9 https://github.com/rails/rails/blob/5f261d04d6f857d49c75124df809adfbd6cd5b5e/activerecord/lib/active_record/touch_later.rb#L25 But I can't find any other implicit commit/rollback callbacks in our code base at least now. I think the `self.class.connection.add_transaction_record(self)` line doesn't cover any behavior.
* Enable SQL statement cache for `find` on base class as with `find_by`Ryuta Kamizono2019-03-011-1/+1
| | | | Related and follows d333d85254d27cd572e6ecce8ee850c107a4f340.
* Don't cache `find_by` statements on STI subclassesRyuta Kamizono2019-02-271-1/+2
| | | | | | Caching `find_by` statements on STI subclasses is unsafe, since `type IN (?,?,?,?)` part is dynamic, and we don't have SQL statements cache invalidation when a STI subclass is created or removed for now.
* Improve performance of blank? and present? in an ActiveRecord::Base instanceRafael Mendonça França2019-02-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this benchmark: require "bundler/setup" require "active_record" require "benchmark/ips" # This connection will do for database-independent bug reports. ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:") ActiveRecord::Schema.define do create_table :posts, force: true do |t| end end class Post < ActiveRecord::Base end new_post = Post.new Benchmark.ips do |b| b.report("present?") do new_post.present? end b.report("blank?") do new_post.blank? end end Before: Warming up -------------------------------------- present? 52.147k i/100ms blank? 53.077k i/100ms Calculating ------------------------------------- present? 580.184k (±21.8%) i/s - 2.555M in 5.427085s blank? 601.537k (± 9.2%) i/s - 2.972M in 5.003503s After: Warming up -------------------------------------- present? 378.235k i/100ms blank? 375.476k i/100ms Calculating ------------------------------------- present? 17.381M (± 7.5%) i/s - 86.238M in 5.001815s blank? 17.877M (± 6.4%) i/s - 88.988M in 5.004634s This improvement is mostly because those methods were hitting `method_missing` on a lot of levels to be able to return the value. To avoid all this stack walking we are short-circuiting those methods. Closes #35059.
* Add ability to change the names of the default handlersEileen Uchitelle2019-02-011-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | When I wrote the `connected_to` and `connects_to` API's I wrote them with the idea in mind that it didn't really matter what the handlers/roles were called as long as those connecting to the roles knew which one wrote and which one read. With the introduction of the middleware Rails begins to assume it's `writing` and `reading` and there's no room for other roles. At GitHub we've been using this method for a long time so we have a ton of legacy code that uses different handler names `default` and `readonly`. We could rename all our code but I think this is better for a few reasons: - Legacy apps that have been using multiple databases for a long time can have an eaiser time switching. - If we later find this to cause more issues than it's worth we can easily deprecate. - We won't force old apps to rewrite the resolver middleware just to use a different handler. Adding the writing_role/reading_role required that I move the code that creates the first handler for writing to the railtie. If I didn't move this the core class would assign the handler before I was able to assign a new one in my configuration and I'd end up with 3 handlers instead of 2.
* Adds basic automatic database switching to RailsEileen Uchitelle2019-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following PR adds behavior to Rails to allow an application to automatically switch it's connection from the primary to the replica. A request will be sent to the replica if: * The request is a read request (`GET` or `HEAD`) * AND It's been 2 seconds since the last write to the database (because we don't want to send a user to a replica if the write hasn't made it to the replica yet) A request will be sent to the primary if: * It's not a GET/HEAD request (ie is a POST, PATCH, etc) * Has been less than 2 seconds since the last write to the database The implementation that decides when to switch reads (the 2 seconds) is "safe" to use in production but not recommended without adequate testing with your infrastructure. At GitHub in addition to the a 5 second delay we have a curcuit breaker that checks the replication delay and will send the query to a replica before the 5 seconds has passed. This is specific to our application and therefore not something Rails should be doing for you. You'll need to test and implement more robust handling of when to switch based on your infrastructure. The auto switcher in Rails is meant to be a basic implementation / API that acts as a guide for how to implement autoswitching. The impementation here is meant to be strict enough that you know how to implement your own resolver and operations classes but flexible enough that we're not telling you how to do it. The middleware is not included automatically and can be installed in your application with the classes you want to use for the resolver and operations passed in. If you don't pass any classes into the middleware the Rails default Resolver and Session classes will be used. The Resolver decides what parameters define when to switch, Operations sets timestamps for the Resolver to read from. For example you may want to use cookies instead of a session so you'd implement a Resolver::Cookies class and pass that into the middleware via configuration options. ``` config.active_record.database_selector = { delay: 2.seconds } config.active_record.database_resolver = MyResolver config.active_record.database_operations = MyResolver::MyCookies ``` Your classes can inherit from the existing classes and reimplment the methods (or implement more methods) that you need to do the switching. You only need to implement methods that you want to change. For example if you wanted to set the session token for the last read from a replica you would reimplement the `read_from_replica` method in your resolver class and implement a method that updates a new timestamp in your operations class.
* Ensure `StatementCache#execute` never raises `RangeError`Ryuta Kamizono2019-01-181-7/+2
| | | | | | | | | | | | | Since 31ffbf8d, finder methods no longer raise `RangeError`. So `StatementCache#execute` is the only place to raise the exception for finder queries. `StatementCache` is used for simple equality queries in the codebase. This means that if `StatementCache#execute` raises `RangeError`, the result could always be regarded as empty. So `StatementCache#execute` just return nil in that range error case, and treat that as empty in the caller side, then we can avoid catching the exception in much places.
* Merge pull request #33985 from eugeneius/attribute_methods_schema_cacheKasper Timm Hansen2019-01-031-0/+4
|\ | | | | Only define attribute methods from schema cache
| * Only define attribute methods from schema cacheEugene Kenny2018-09-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | To define the attribute methods for a model, Active Record needs to know the schema of the underlying table, which is usually achieved by making a request to the database. This is undesirable behaviour while the app is booting, for two reasons: it makes the boot process dependent on the availability of the database, and it means every new process will make one query for each table, which can cause issues for large applications. However, if the application is using the schema cache dump feature, then the schema cache already contains the necessary information, and we can define the attribute methods without causing any extra database queries.
* | Bring ActiveRecord::Core's API document back [ci skip]yuuji.yaginuma2019-01-021-3/+1
| | | | | | | | | | If exist `:nodoc:` before method define, it affects all subsequent method definitions.
* | Make connection handler per thread instead of per fiberEileen Uchitelle2018-11-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The connection handler was using the RuntimeRegistry which kind of implies it's a per thread registry. But it's actually per fiber. If you have an application that uses fibers and you're using multiple databases, when you switch the connection handler to swap connections new fibers running on the same thread used to get a different connection id. This PR changes the code to actually use a thread so that we get the same connection. Fixes https://github.com/rails/rails/issues/30047 [Eileen M. Uchitelle, Aaron Patterson, & Arthur Neeves]
* | Fix inspect with non-primary key id attributeEugene Kenny2018-11-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | The `read_attribute` method always returns the primary key when asked to read the `id` attribute, even if the primary key isn't named `id`, and even if another attribute named `id` exists. For the `inspect`, `attribute_for_inspect` and `pretty_print` methods, this behaviour is undesirable, as they're used to examine the internal state of the record. By using `_read_attribute` instead, we'll get the real value of the `id` attribute.
* | Merge pull request #34208 from yskkin/inspect_with_parameter_filterRyuta Kamizono2018-10-261-19/+22
|\ \ | | | | | | Implement AR#inspect using ParameterFilter
| * | Implement AR#inspect using ParamterFilter.Yoshiyuki Kinjo2018-10-191-19/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | AR instance support `filter_parameters` since #33756. Though Regex or Proc is valid as `filter_parameters`, they are not supported as AR#inspect. I also add :mask option and #filter_params to `ActiveSupport::ParameterFilter#new` to implement this.
* | | Consolidate duplicated code that initializing an empty model objectRyuta Kamizono2018-10-171-19/+7
|/ / | | | | | | | | | | | | | | | | | | | | | | | | `init_with` and `init_from_db` are almost the same code except decode `coder`. And also, named `init_from_db` is a little misreading, a raw values hash from the database is already converted to an attributes object by `attributes_builder.build_from_database`, so passed `attributes` in that method is just an attributes object. I renamed that method to `init_with_attributes` since the method is shared with `init_with` to initialize an empty model object.
* / Basic API for connection switchingEileen Uchitelle2018-10-101-0/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR adds the ability to 1) connect to multiple databases in a model, and 2) switch between those connections using a block. To connect a model to a set of databases for writing and reading use the following API. This API supercedes `establish_connection`. The `writing` and `reading` keys represent handler / role names and `animals` and `animals_replica` represents the database key to look up the configuration hash from. ``` class AnimalsBase < ApplicationRecord connects_to database: { writing: :animals, reading: :animals_replica } end ``` Inside the application - outside the model declaration - we can switch connections with a block call to `connected_to`. If we want to connect to a db that isn't default (ie readonly_slow) we can connect like this: Outside the model we may want to connect to a new database (one that is not in the default writing/reading set) - for example a slow replica for making slow queries. To do this we have the `connected_to` method that takes a `database` hash that matches the signature of `connects_to`. The `connected_to` method also takes a block. ``` AcitveRecord::Base.connected_to(database: { slow_readonly: :primary_replica_slow }) do ModelInPrimary.do_something_thats_slow end ``` For models that are already loaded and connections that are already connected, `connected_to` doesn't need to pass in a `database` because you may want to run queries against multiple databases using a specific role/handler. In this case `connected_to` can take a `role` and use that to swap on the connection passed. This simplies queries - and matches how we do it in GitHub. Once you're connected to the database you don't need to re-connect, we assume the connection is in the pool and simply pass the handler we'd like to swap on. ``` ActiveRecord::Base.connected_to(role: :reading) do Dog.read_something_from_dog ModelInPrimary.do_something_from_model_in_primary end ```
* Add mention about `ActiveRecord::Base::filter_attributes` to the changelog entrybogdanvlviv2018-09-121-6/+6
| | | | | 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
* Build string set when `filter_attributes` is assignedbogdanvlviv2018-09-121-6/+17
| | | | | | | | | 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.
* DRY `activerecord/lib/active_record/core.rb` and fix testsbogdanvlviv2018-09-121-6/+9
| | | | | | | | | | | | | | | | | | | - 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
* Clarify docs of `config.filter_parameters` and `#filter_attributes`bogdanvlviv2018-09-121-1/+1
| | | | | Add mention that `config.filter_parameters` also filters out sensitive values of database columns when call `#inspect` since #33756.
* Configuration item `config.filter_parameters` could also filter out ↵Zhang Kang2018-09-071-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | 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] ...> ```
* Refactors Active Record connection managementEileen Uchitelle2018-08-301-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [ci skip] Change references from Rake task to Rails commandAlberto Almagro2018-08-011-1/+1
| | | | | This commit follows the path we started at commit #ea4f0e2 and continued at PR #33229.
* define attribute methods in `init_from_db`Aaron Patterson2018-06-261-0/+2
| | | | | Now that `allocate` is removed, we need to define attribute methods in all "init" methods.
* Merge branch 'master' into homogeneous-allocationAaron Patterson2018-06-261-5/+0
|\ | | | | | | | | | | | | | | * 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
| * Call initialize after allocateAaron Patterson2018-06-261-5/+0
| | | | | | | | | | | | | | | | 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.
* | Speed up homogeneous AR lists / reduce allocationsAaron Patterson2018-06-251-0/+20
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ```
* Clear the transaction state when AR object is dupedYuriy Ustushenko2018-01-251-2/+4
|
* Avoid passing unnecessary arguments to relationDaniel Colson2018-01-241-1/+1
| | | | | | | | | | | | 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?
* Log call site for all queriesOlivier Lacan2017-12-131-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Prevent extra `spawn` to make `klass.all` faster (#29009)Ryuta Kamizono2017-11-201-1/+2
| | | | | | | | | | | | | | | | | | | | 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 ```
* remove :enabled optionBen Toews2017-11-091-3/+2
|
* add config to check arguments to unsafe AR methodsBen Toews2017-11-091-0/+9
|
* Remove deprecated configuration `.error_on_ignored_order_or_limit`Rafael Mendonça França2017-10-231-20/+0
|
* Update links to use https instead of http [ci skip]Yoshiyuki Hirano2017-08-221-1/+1
|
* Fix outdated comment for `Core::ClassMethods#===` [ci skip] (#30146)Ryuta Kamizono2017-08-121-2/+2
| | | | | | | | | | | | | 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.
* Use `Concurrent::Map` than `Mutex` and `Mutex_m` for statement cachesRyuta Kamizono2017-08-041-4/+3
| | | | | Statement caches are used as a concurrent map. It will more clarify to using `Concurrent::Map`.
* Passing `klass` to `StatementCache.new`Ryuta Kamizono2017-08-041-2/+2
| | | | | | 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.
* Merge pull request #29842 from kamipo/fix_find_by_with_rangeMatthew Draper2017-08-021-3/+2
|\ | | | | Fix `find_by` with range conditions
| * Fix `find_by` with range conditionsRyuta Kamizono2017-07-201-3/+2
| | | | | | | | | | `StatementCache` doesn't support range conditions. So we need to through the args to `FinderMethods#find_by` if range value is passed.
* | Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
|/
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-16 09:55:55 +0000