aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/locking
Commit message (Collapse)AuthorAgeFilesLines
* Enable `Layout/EmptyLinesAroundAccessModifier` copRyuta Kamizono2019-06-131-1/+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.
* PERF: 20% faster pk attribute accessRyuta Kamizono2019-04-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ```
* Fix dirty tracking for `touch`Ryuta Kamizono2019-04-151-2/+1
| | | | | | | | | | Before this fix, `touch` only clears dirty tracking for touched attributes, doesn't track saved (touched) changes. This fixes that tracks saved changes and carry over remaining changes. Fixes #33429. Closes #34306.
* Fix example for database-specific locking clauseGannon McGibbon2018-10-301-3/+3
| | | | [ci skip]
* Remove unused splat args in `_create_record`Ryuta Kamizono2018-09-021-1/+1
| | | | | | | | | | | | `_create_record` is passed `attribute_names` only. ``` % git grep -n '_create_record(attribute_names' lib/active_record/attribute_methods/dirty.rb:173: def _create_record(attribute_names = attribute_names_for_partial_writes) lib/active_record/counter_cache.rb:162: def _create_record(attribute_names = self.attribute_names) lib/active_record/locking/optimistic.rb:64: def _create_record(attribute_names = self.attribute_names) lib/active_record/persistence.rb:738: def _create_record(attribute_names = self.attribute_names) ```
* Use strings instead of symbols on calls to decorate_matching_attribute_typesDillon Welch2018-08-101-1/+1
| | | | | | The first thing this method does is run on the argument. This change passes in a string so we don't allocate a bunch of unnecessary extra strings by calling to_s on a symbol over and over.
* Merge pull request #30956 from CJStadler/with-lock-changed-deprecationRafael França2018-03-281-1/+1
| | | | Fix deprecation warnings from with_lock
* Fix that after commit callbacks on update does not triggered when optimistic ↵Ryuta Kamizono2018-03-061-43/+6
| | | | | | | | | | | | | | | | | | 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.
* Introduce `_update_row` to decouple optimistic locking concern from ↵Ryuta Kamizono2018-03-051-0/+31
| | | | `Persistence` module
* Introduce `_delete_record` and use it for deleting a recordRyuta Kamizono2018-03-051-13/+9
|
* Prefer `_update_record` than `update_all` for updating a recordRyuta Kamizono2018-03-051-5/+2
|
* Refactor `_substitute_values` to be passed attribute names and valuesRyuta Kamizono2018-03-051-3/+1
|
* `id_in_database` should be respected as primary key value for persisted recordsRyuta Kamizono2018-03-051-1/+1
| | | | | | | | | | | | 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.
* Ensure we don't write virtual attributes on update, tooSean Griffin2018-02-261-0/+1
| | | | See 948b931925febac3c965ab13470065ced68f7b53 for context
* Rase when calling `lock!` in a dirty recordRafael Mendonça França2017-10-231-4/+5
|
* Update links to use https instead of http [ci skip]Yoshiyuki Hirano2017-08-221-1/+1
|
* Change http postgresql.org links to https [ci skip]yuuji.yaginuma2017-07-301-1/+1
| | | | | It seems that it accepts only HTTPS connections. Ref: https://github.com/postgres/postgres/commit/7f77cbd996855a06fb742ea11adbe55c42b48fe2
* Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-192-0/+4
|
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-022-2/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-012-0/+2
|
* Fix destroy with locking_column value nullbogdanvlviv2017-06-201-1/+1
| | | | | | | Fix destroying existing object does not work well when optimistic locking enabled and `locking column` is null in the database. Follow 22a822e5813ef7ea9ab6dbbb670a363899a083af, #28914
* Clean up 'Optimistic Locking' implementationbogdanvlviv2017-06-121-3/+4
|
* Add option for class_attribute default (#29270)David Heinemeier Hansson2017-05-291-2/+1
| | | | | | | | | | | | * Allow a default value to be declared for class_attribute * Convert to using class_attribute default rather than explicit setter * Removed instance_accessor option by mistake * False is a valid default value * Documentation
* Remove ability update locking_column valuebogdanvlviv2017-03-161-6/+2
|
* Deprecate locking of dirty recordsMarc Schütz2017-02-071-1/+10
|
* No need to nodoc private methodsAkira Matsuda2016-12-241-2/+2
|
* Small grammar fix for #26867Jon Moss2016-10-231-1/+2
| | | | [ci skip]
* Add info about updating locking column valuebogdanvlviv2016-10-231-0/+1
| | | | | [ci skip] Follow #26050
* Added ability update locking_column valuebogdanvlviv2016-10-211-6/+8
|
* Fixed: Optimistic locking does not work well with null in the databasebogdanvlviv2016-10-211-4/+6
|
* Fix broken comments indentation caused by rubocop auto-correct [ci skip]Ryuta Kamizono2016-09-141-4/+4
| | | | | | All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772. But comments was still kept absolute position. This commit aligns comments with method definitions for consistency.
* Add `Style/EmptyLines` in `.rubocop.yml` and remove extra empty linesRyuta Kamizono2016-08-071-1/+0
|
* normalizes indentation and whitespace across the projectXavier Noria2016-08-061-43/+43
|
* modernizes hash syntax in activerecordXavier Noria2016-08-061-1/+1
|
* applies new string literal convention in activerecord/libXavier Noria2016-08-061-5/+5
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Move comment up to the class, for both of the methods, and document on class ↵Vipul A M2016-05-011-1/+4
| | | | | | level why we are doing this. [ci skip]
* schema_load triggers 2nd schema_load (via locking)Keenan Brock2016-04-281-1/+1
| | | | | | | | | | | | | | Currently, loading the schema (schema_load) accesses the locking column (locking_column) which defaults the value (reset_locking_column) which invalidates the schema (reload_schema_from_cache) which forces another schema load. Good news: The second schema_load does accesses locking_column, but locking_column is set, so it does not reset_locking_column and it does not trigger an infinite loop. The solution is not invalidate the cache while default locking_column
* Followup of #15771Vipul A M2016-04-241-0/+4
| | | | | | | | | Make sure we handle explicitly passed nil's to lock_version as well. An explicitly passed nil value is now converted to 0 on LockingType, so that we don't end up with ActiveRecord::StaleObjectError in update record optimistic locking Fixes #24695
* Fix ActiveRecord::Locking doc [ci skip]Mehmet Emin İNAÇ2015-09-241-2/+2
|
* Updated MySQL documentation link to MySQL latest version 5.7 everywhere [ci ↵amitkumarsuroliya2015-09-101-1/+1
| | | | | skip] Bumps from `5.6` to `5.7`
* Update old link in pessimistic.rb commentsAlexander Leishman2015-03-181-1/+1
| | | Update link in comments to point to latest MySQL production version documentation. See here for reference: http://dev.mysql.com/doc/refman/5.0/en/choosing-version.html
* Call `attributes_for_update` in `_update_record` w/ optimistic lockingSean Griffin2015-02-241-1/+1
| | | | Fixes #19057
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-171-1/+1
|
* Change `LockingType` to use `DelegateClass`Sean Griffin2015-02-091-1/+1
| | | | Significantly faster than `SimpleDelegator`.
* Attribute assignment and type casting has nothing to do with columnsSean Griffin2015-01-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's finally finished!!!!!!! The reason the Attributes API was kept private in 4.2 was due to some publicly visible implementation details. It was previously implemented by overloading `columns` and `columns_hash`, to make them return column objects which were modified with the attribute information. This meant that those methods LIED! We didn't change the database schema. We changed the attribute information on the class. That is wrong! It should be the other way around, where schema loading just calls the attributes API for you. And now it does! Yes, this means that there is nothing that happens in automatic schema loading that you couldn't manually do yourself. (There's still some funky cases where we hit the connection adapter that I need to handle, before we can turn off automatic schema detection entirely.) There were a few weird test failures caused by this that had to be fixed. The main source came from the fact that the attribute methods are now defined in terms of `attribute_names`, which has a clause like `return [] unless table_exists?`. I don't *think* this is an issue, since the only place this caused failures were in a fake adapter which didn't override `table_exists?`. Additionally, there were a few cases where tests were failing because a migration was run, but the model was not reloaded. I'm not sure why these started failing from this change, I might need to clear an additional cache in `reload_schema_from_cache`. Again, since this is not normal usage, and it's expected that `reset_column_information` will be called after the table is modified, I don't think it's a problem. Still, test failures that were unrelated to the change are worrying, and I need to dig into them further. Finally, I spent a lot of time debugging issues with the mutex used in `define_attribute_methods`. I think we can just remove that method entirely, and define the attribute methods *manually* in the call to `define_attribute`, which would simplify the code *tremendously*. Ok. now to make this damn thing public, and work on moving it up to Active Model.
* Go through normal where logic in destroy with lockingSean Griffin2015-01-141-6/+2
| | | | | | Building the Arel AST, and manipulating the relation manually like this is prone to errors and breakage as implementation details change from underneath it.
* Properly persist `lock_version` as 0 if the DB has no defaultSean Griffin2015-01-091-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | The reason this bug occured is that we never actually check to see if this column has changed from it's default, since it was never assigned and is not mutable. It appears I was wrong in b301c40224c6d15b539dbcc7485adb44d810f88c, with my statement of "there is no longer a case where a given value would differ from the default, but would not already be marked as changed." However, I chose not to revert the deletion of `initialize_internals_callback` from that commit, as I think a solution closer to where the problem lies is less likely to get erroneously removed. I'm not super happy with this solution, but it mirrors what is being done in `_update_record`, and a fix for one should work for the other. I toyed with the idea of changing the definition of `changed?` on the type to `changed_in_place?`. If we type cast the raw value, it'll break a test about updating not modifying the lock column if nothing else was changed. We could have the definition check if `raw_old_value` is `nil`, but this feels fragile and less intention revealing. It would, however, have the benefit of cleaning up old data that incorrectly persisted as `nil`. Fixes #18422
* Tiny documentation fixes [ci skip]Robin Dupret2014-12-301-1/+1
|
* Go through normal `update_all` logic when updating lock columnsSean Griffin2014-12-261-17/+7
|
* We don't need additional type casting for locking updatesSean Griffin2014-12-261-3/+11
| | | | | | | Part of the larger refactoring to remove type casting from Arel. We can inform it that we already have the right type by wrapping the value in an `Arel::Nodes::Quoted`. This commit can be reverted when we have removed type casting from Arel in Rail 5.1
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-18 12:45:18 +0000