aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/associations/required_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* Enable `Style/RedundantBegin` cop to avoid newly adding redundant begin blockRyuta Kamizono2018-12-211-27/+23
| | | | | | | | | | Currently we sometimes find a redundant begin block in code review (e.g. https://github.com/rails/rails/pull/33604#discussion_r209784205). I'd like to enable `Style/RedundantBegin` cop to avoid that, since rescue/else/ensure are allowed inside do/end blocks in Ruby 2.5 (https://bugs.ruby-lang.org/issues/12906), so we'd probably meets with that situation than before.
* 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
|
* Ensure that tests will reset belongs_to_requierd_by_default configCarlos Figueiredo2017-02-271-23/+27
|
* Make required by default test for belongs_to association clearerCarlos Figueiredo2017-02-271-1/+25
| | | | | | | | | | | | | Since #18937 `belongs_to` associations receive a setting to determine if it should be or not treated as `required` by default. While the tests were still passing, it was not evident that the "default" behaviour for `required` could change in fuction of a setting, that is set by default for fresh Rails5 apps, but not for upgraded apps. This commit try to relate them to make it clear what is the behaviour expected when the setting is set as `true` or not set.
* normalizes indentation and whitespace across the projectXavier Noria2016-08-061-6/+6
|
* applies new string literal convention in activerecord/testXavier Noria2016-08-061-2/+2
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Closes rails/rails#18864: Renaming transactional fixtures to transactional testsBrandon Weiss2015-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Provide a better error message on :required associationHenrik Nygren2015-01-281-2/+22
| | | | Fixes #18696.
* tests, use `drop_table if_exists: true` in our test suite.Yves Senn2015-01-201-2/+2
|
* Replace drop sql statement to drop_table methodYasuo Honda2014-09-111-2/+2
| | | | to drop sequences at the same time each tables dropped for Oracle
* Remove 'if exists' from drop table statement then use `table_exists?`Yasuo Honda2014-09-031-2/+2
| | | | | Since 'drop table if exists' statement does not always work with some databases such as Oracle.
* Add a `required` option to singular associationsSean Griffin2014-07-041-0/+82
In addition to defining the association, a `required` association will also have its presence validated. Before: ```ruby belongs_to :account validates_presence_of :account ``` After: ```ruby belongs_to :account, required: true ``` This helps to draw a distinction between types of validations, since validations on associations are generally for data integrity purposes, and aren't usually set through form inputs.