aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/locking_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* Fix `touch` option to behave consistently with `Persistence#touch` methodRyuta Kamizono2018-06-181-9/+15
| | | | | | | | | | | | | | | | `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.
* Merge pull request #30956 from CJStadler/with-lock-changed-deprecationRafael França2018-03-281-0/+11
| | | | Fix deprecation warnings from with_lock
* `id_in_database` should be respected as primary key value for persisted recordsRyuta Kamizono2018-03-051-0/+39
| | | | | | | | | | | | 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.
* Fix `test_counter_cache_with_touch_and_lock_version` failurebogdanvlviv2018-02-071-1/+3
| | | | | | https://travis-ci.org/rails/rails/jobs/338338927#L1043 Related to daf15f58b943d85d8fb726590ae94f77ca0a5d5f
* Use assert_empty and assert_not_emptyDaniel Colson2018-01-251-3/+3
|
* Use assert_predicate and assert_not_predicateDaniel Colson2018-01-251-11/+11
|
* Change refute to assert_notDaniel Colson2018-01-251-1/+1
|
* Fix `test_counter_cache_with_touch_and_lock_version` failureRyuta Kamizono2017-12-181-2/+2
| | | | | | Looks like it is failed due to datetime rounding. Related #23521. https://travis-ci.org/rails/rails/jobs/317734560#L1980-L1984
* Fix conflicts `counter_cache` with `touch: true` by optimistic locking.bogdanvlviv2017-12-121-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``` # create_table :posts do |t| # t.integer :comments_count, default: 0 # t.integer :lock_version # t.timestamps # end class Post < ApplicationRecord end # create_table :comments do |t| # t.belongs_to :post # end class Comment < ApplicationRecord belongs_to :post, touch: true, counter_cache: true end ``` Before: ``` post = Post.create! # => begin transaction INSERT INTO "posts" ("created_at", "updated_at", "lock_version") VALUES ("2017-12-11 21:27:11.387397", "2017-12-11 21:27:11.387397", 0) commit transaction comment = Comment.create!(post: post) # => begin transaction INSERT INTO "comments" ("post_id") VALUES (1) UPDATE "posts" SET "comments_count" = COALESCE("comments_count", 0) + 1, "lock_version" = COALESCE("lock_version", 0) + 1 WHERE "posts"."id" = 1 UPDATE "posts" SET "updated_at" = '2017-12-11 21:27:11.398330', "lock_version" = 1 WHERE "posts"."id" = 1 AND "posts"."lock_version" = 0 rollback transaction # => ActiveRecord::StaleObjectError: Attempted to touch a stale object: Post. Comment.take.destroy! # => begin transaction DELETE FROM "comments" WHERE "comments"."id" = 1 UPDATE "posts" SET "comments_count" = COALESCE("comments_count", 0) - 1, "lock_version" = COALESCE("lock_version", 0) + 1 WHERE "posts"."id" = 1 UPDATE "posts" SET "updated_at" = '2017-12-11 21:42:47.785901', "lock_version" = 1 WHERE "posts"."id" = 1 AND "posts"."lock_version" = 0 rollback transaction # => ActiveRecord::StaleObjectError: Attempted to touch a stale object: Post. ``` After: ``` post = Post.create! # => begin transaction INSERT INTO "posts" ("created_at", "updated_at", "lock_version") VALUES ("2017-12-11 21:27:11.387397", "2017-12-11 21:27:11.387397", 0) commit transaction comment = Comment.create!(post: post) # => begin transaction INSERT INTO "comments" ("post_id") VALUES (1) UPDATE "posts" SET "comments_count" = COALESCE("comments_count", 0) + 1, "lock_version" = COALESCE("lock_version", 0) + 1, "updated_at" = '2017-12-11 21:37:09.802642' WHERE "posts"."id" = 1 commit transaction comment.destroy! # => begin transaction DELETE FROM "comments" WHERE "comments"."id" = 1 UPDATE "posts" SET "comments_count" = COALESCE("comments_count", 0) - 1, "lock_version" = COALESCE("lock_version", 0) + 1, "updated_at" = '2017-12-11 21:39:02.685520' WHERE "posts"."id" = 1 commit transaction ``` Fixes #31199.
* Should pass `test_no_locks_no_wait` not only on `PostgreSQLAdapter` and ↵Ryuta Kamizono2017-11-091-8/+5
| | | | `OracleAdapter`
* Rase when calling `lock!` in a dirty recordRafael Mendonça França2017-10-231-11/+11
|
* Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
|
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
|
* Fix ActiveRecord::Persistence#touch with lockingbogdanvlviv2017-06-211-2/+25
| | | | | | `ActiveRecord::Persistence#touch` does not work well when optimistic locking enabled and `locking_column`, without default value, is null in the database.
* Fix destroy with locking_column value nullbogdanvlviv2017-06-201-0/+25
| | | | | | | Fix destroying existing object does not work well when optimistic locking enabled and `locking column` is null in the database. Follow 22a822e5813ef7ea9ab6dbbb670a363899a083af, #28914
* Add test cases for optimistic lockingbogdanvlviv2017-06-121-0/+19
| | | | | | | | | Add test to ensure that locking_column cannot be updated explicitly. Add test to prevent regression on creating new object with explicit value locking_column. Related to #28318
* Remove ability update locking_column valuebogdanvlviv2017-03-161-34/+0
|
* Deprecate locking of dirty recordsMarc Schütz2017-02-071-1/+4
|
* `self.` is not needed when calling its own instance methodAkira Matsuda2017-01-051-1/+1
| | | | Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
* Privatize unneededly protected methods in Active Record testsAkira Matsuda2016-12-241-1/+1
|
* Add more rubocop rules about whitespacesRafael Mendonça França2016-10-291-1/+1
|
* Added ability update locking_column valuebogdanvlviv2016-10-211-0/+76
|
* Fixed: Optimistic locking does not work well with null in the databasebogdanvlviv2016-10-211-11/+55
|
* Clear attribute changes after handling lockingJakob Skjerning2016-09-141-0/+1
| | | | | | | | | | | | | | | | | Without this the changes to the lock version column will stick around even after `touch` returns. Before: model.touch model.changes # => {"lock_version"=>[0, "1"]} After: model.touch model.changes # {}
* 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-23/+23
|
* modernizes hash syntax in activerecordXavier Noria2016-08-061-12/+12
|
* applies new string literal convention in activerecord/testXavier Noria2016-08-061-53/+53
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Followup of #15771Vipul A M2016-04-241-0/+6
| | | | | | | | | 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 tests failure with `prepared_statements: false`Ryuta Kamizono2016-02-291-1/+1
| | | | | | Some tests does not work for unprepared statements. Add `if ActiveRecord::Base.connection.prepared_statements` and fix a regex for fix tests failure with `prepared_statements: false`.
* Fix test failures caused by 574f255Sean Griffin2015-12-141-1/+1
| | | | | There was a test remaining for PG only that was checking for an exact limit clause
* Fix the test that was broken by #16445 rather than deleting itSean Griffin2015-07-191-0/+12
| | | | | | | | Since the counter cache was properly being updated, the model became stale. Simply reloading the model before attempting to destroy is sufficient for this case. I believe this is enough of an edge case to be a valid change to the tests, even though it represents a potential breaking change.
* Fix counter_cache for polymorphic associationsStefan Kanev2015-07-191-12/+0
| | | | | | | | | | | | | | Also removes a false positive test that depends on the fixed bug: At this time, counter_cache does not work with polymorphic relationships (which is a bug). The test was added to make sure that no StaleObjectError is raised when the car is destroyed. No such error is currently raised because the lock version is not incremented by appending a wheel to the car. Furthermore, `assert_difference` succeeds because `car.wheels.count` does not check the counter cache, but the collection size. The test will fail if it is replaced with `car.wheels_count || 0`.
* Raise StaleObjectError if touched object is stale and locking is enabledMehmet Emin İNAÇ2015-04-191-0/+10
| | | | | | | | | | Fixes #19776 change test variable names and use more verbose on method less verbose use _read_attribute instead of send
* Closes rails/rails#18864: Renaming transactional fixtures to transactional testsBrandon Weiss2015-03-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | I’m renaming all instances of `use_transcational_fixtures` to `use_transactional_tests` and “transactional fixtures” to “transactional tests”. I’m deprecating `use_transactional_fixtures=`. So anyone who is explicitly setting this will get a warning telling them to use `use_transactional_tests=` instead. I’m maintaining backwards compatibility—both forms will work. `use_transactional_tests` will check to see if `use_transactional_fixtures` is set and use that, otherwise it will use itself. But because `use_transactional_tests` is a class attribute (created with `class_attribute`) this requires a little bit of hoop jumping. The writer method that `class_attribute` generates defines a new reader method that return the value being set. Which means we can’t set the default of `true` using `use_transactional_tests=` as was done previously because that won’t take into account anyone using `use_transactional_fixtures`. Instead I defined the reader method manually and it checks `use_transactional_fixtures`. If it was set then it should be used, otherwise it should return the default, which is `true`. If someone uses `use_transactional_tests=` then it will overwrite the backwards-compatible method with whatever they set.
* Properly persist `lock_version` as 0 if the DB has no defaultSean Griffin2015-01-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Go through normal `update_all` logic when updating lock columnsSean Griffin2014-12-261-2/+0
|
* Dynamically modified schema and association would not be correctly resetAkira Matsuda2014-09-061-16/+9
| | | | | This fixes <"SQLite3::SQLException: no such column: legacy_things.person_id: SELECT \"legacy_things\".* FROM \"legacy_things\" WHERE \"legacy_things\".\"person_id\" = ?"> in OptimisticLockingTest#test_lock_destroy
* Reset schema properly after schema changing testAkira Matsuda2014-08-281-0/+2
|
* Don't mess with `column_defaults` when optimistic locking is enabledSean Griffin2014-06-171-0/+7
|
* Remove deprecated method ActiveRecord::Base.quoted_locking_columnAkshay Vishnoi2014-06-101-4/+0
|
* Remove dead test code for unsupported adaptersSean Griffin2014-05-171-3/+1
|
* Correctly send the string given to lock! and reload(:lock) to the lock scope ↵Mauricio Linhares2014-01-291-0/+11
| | | | | | - fixes #13788 As per the documentation at lock!, if the :lock option is a string it should use the given SQL to generate the lock statement.
* Deprecate unused quoted_locking_column method.kennyj2013-09-241-0/+4
|
* Tidy up the "Specified column type for quote_value" changesBen Woosley2013-07-221-1/+0
| | | | | | This includes fixing typos in changelog, removing a deprecated mocha/setup test require, and preferring the `column_for_attribute` accessor over direct access to the columns_hash in the new code.
* Specified column type for quote_valueAlfred Wong2013-07-221-0/+13
| | | | | | | | | | | | | | | | | | | | | When calling quote_value the underlying connection sometimes requires more information about the column to properly return the correct quoted value. I ran into this issue when using optimistic locking in JRuby and the activerecord-jdbcmssql-adapter. In SQLSever 2000, we aren't allowed to insert a integer into a NVARCHAR column type so we need to format it as N'3' if we want to insert into the NVARCHAR type. Unfortuantely, without the column type being passed the connection adapter cannot properly return the correct quote value because it doesn't know to return N'3' or '3'. This patch is fairly straight forward where it just passes in the column type into the quote_value, as it already has the ability to take in the column, so it can properly handle at the connection level. I've added the tests required to make sure that the quote_value method is being passed the column type so that the underlying connection can determine how to quote the value.
* Reset @column_defaults when assigning .kennyj2013-07-141-0/+1
|
* Do not invoke callbacks when delete_all is calledNeeraj Singh2013-06-301-0/+1
| | | | | | | | | | | Method `delete_all` should not be invoking callbacks and this feature was deprecated in Rails 4.0. This is being removed. `delete_all` will continue to honor the `:dependent` option. However if `:dependent` value is `:destroy` then the default deletion strategy for that collection will be applied. User can also force a deletion strategy by passing parameter to `delete_all`. For example you can do `@post.comments.delete_all(:nullify)`
* indentationAaron Patterson2013-06-111-1/+1
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 05:53:15 +0000