aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/attribute_methods
Commit message (Collapse)AuthorAgeFilesLines
* initialize generated modules on inclusion and on inheritenceAaron Patterson2013-07-021-7/+0
|
* remove private attribute readerAaron Patterson2013-07-021-2/+2
|
* just construct real objects rather than mock and stubAaron Patterson2013-06-171-7/+8
|
* add test for 9041454def79d8e61cabe49e7c5cb72cef29138bJan Berdajs2013-06-051-0/+28
|
* Remove ActiveRecord::ModelJon Leighton2012-10-261-2/+0
| | | | | | | | | | In the end I think the pain of implementing this seamlessly was not worth the gain provided. The intention was that it would allow plain ruby objects that might not live in your main application to be subclassed and have persistence mixed in. But I've decided that the benefit of doing that is not worth the amount of complexity that the implementation introduced.
* removes usage of Object#in? from the code base (the method remains defined ↵Xavier Noria2012-08-061-2/+2
| | | | | | | | | | | | | | | | | | | by Active Support) Selecting which key extensions to include in active_support/rails made apparent the systematic usage of Object#in? in the code base. After some discussion in https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d we decided to remove it and use plain Ruby, which seems enough for this particular idiom. In this commit the refactor has been made case by case. Sometimes include? is the natural alternative, others a simple || is the way you actually spell the condition in your head, others a case statement seems more appropriate. I have chosen the one I liked the most in each case.
* load active_support/core_ext/object/inclusion in active_support/railsXavier Noria2012-08-021-1/+0
|
* Simplify AR configuration code.Jon Leighton2012-06-151-0/+1
| | | | | Get rid of ActiveModel::Configuration, make better use of ActiveSupport::Concern + class_attribute, etc.
* Deprecate Column#type_cast_codeCarlos Antonio da Silva2012-03-291-4/+0
|
* Fix another race condition.Jon Leighton2012-01-201-0/+8
| | | | | | From 2c667f69aa2daac5ee6c29ca9679616e2a71532a. Thanks @pwnall for the heads-up.
* Support configuration on ActiveRecord::Model.Jon Leighton2011-12-281-1/+0
| | | | | | | | | | | | | | | The problem: We need to be able to specify configuration in a way that can be inherited to models that include ActiveRecord::Model. So it is no longer sufficient to put 'top level' config on ActiveRecord::Base, but we do want configuration specified on ActiveRecord::Base and descendants to continue to work. So we need something like class_attribute that can be defined on a module but that is inherited when ActiveRecord::Model is included. The solution: added ActiveModel::Configuration module which provides a config_attribute macro. It's a bit specific hence I am not putting this in Active Support or making it a 'public API' at present.
* Deal with global config better between AR::Base and AR::ModelJon Leighton2011-12-241-0/+1
|
* Extract common logic into a methodJon Leighton2011-12-241-0/+1
|
* Fix #4046.Jon Leighton2011-12-231-0/+1
|
* Let AttributeMethods do its own including etcJon Leighton2011-12-151-4/+2
|
* Revert "Raise error on unknown primary key."Jon Leighton2011-10-051-4/+0
| | | | This reverts commit ee2be435b1e5c0e94a4ee93a1a310e0471a77d07.
* Raise error on unknown primary key.Jon Leighton2011-10-051-0/+4
| | | | | If we don't have a primary key when we ask for it, it's better to fail fast. Fixes GH #2307.
* Always generate attribute methods on the base class.Jon Leighton2011-09-131-0/+1
| | | | | | | | | | | | | | This fixes a situation I encountered where a subclass would cache the name of a generated attribute method in @_defined_class_methods. Then, when the superclass has it's attribute methods undefined, the subclass would always have to dispatch through method_missing, because the presence of the attribute in @_defined_class_methods would mean that it is never generated again, even if undefine_attribute_methods is called on the subclass. There various other confusing edge cases like this. STI classes share columns, so let's just keep all the attribute method generation state isolated to the base class.
* please use ruby -I lib:test path/to/test.rb, or export RUBY_OPTAaron Patterson2011-06-061-1/+1
|
* Refactor Active Record test connection setup. Please see the ↵Jon Leighton2011-06-041-1/+1
| | | | RUNNING_UNIT_TESTS file for details, but essentially you can now configure things in test/config.yml. You can also run tests directly via the command line, e.g. ruby path/to/test.rb (no rake needed, uses default db connection from test/config.yml). This will help us fix the CI by enabling us to isolate the different Rails versions to different databases.
* Using Object#in? and Object#either? in various placesPrem Sichanugrist2011-04-111-2/+3
| | | | There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
* oops, no need for puts!Aaron Patterson2011-02-181-1/+0
|
* AR::AttributeMethods does not need to be included in an AR::Base class.Aaron Patterson2011-02-181-0/+62
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 19:13:12 +0000