aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases
Commit message (Collapse)AuthorAgeFilesLines
* Do not run remove_connection in memory db testRafael Mendonça França2015-02-051-7/+7
| | | | This will make rake test_sqlite3_mem work again
* Merge pull request #18809 from meltheadorable/bugfix/postgres_moneySean Griffin2015-02-042-2/+4
|\ | | | | Fix bug causing table creation to fail for models with postgresql 'money' field
| * Fix test cases for money, bit and bit_varyingMelody2015-02-042-2/+4
| |
* | Respect custom primary keys for associations in `Relation#where`Sean Griffin2015-02-041-1/+37
|/ | | | | | | | | | While we query the proper columns, we go through normal handling for converting the value to a primitive which assumes it should use the table's primary key. If the association specifies a different value (and we know that we're working with an association), we should use the custom primary key instead. Fixes #18813.
* rm `Column#cast_type`Sean Griffin2015-02-032-61/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The type from the column is never used, except when being passed to the attributes API. While leaving the type on the column wasn't necessarily a bad thing, I worry that it's existence there implies that it is something which should be used. During the design and implementation process of the attributes API, there have been plenty of cases where getting the "right" type object was hard, but I had easy access to the column objects. For any contributor who isn't intimately familiar with the intents behind the type casting system, grabbing the type from the column might easily seem like the "correct" thing to do. As such, the goal of this change is to express that the column is not something that should be used for type casting. The only places that are "valid" (at the time of this commit) uses of acquiring a type object from the column are fixtures (as the YAML file is going to mirror the database more closely than the AR object), and looking up the type during schema detection to pass to the attributes API Many of the failing tests were removed, as they've been made obsolete over the last year. All of the PG column tests were testing nothing beyond polymorphism. The Mysql2 tests were duplicating the mysql tests, since they now share a column class. The implementation is a little hairy, and slightly verbose, but it felt preferable to going back to 20 constructor options for the columns. If you are git blaming to figure out wtf I was thinking with them, and have a better idea, go for it. Just don't use a type object for this.
* Removed magic comments # encoding: utf-8 , since its default from ruby 2.0 ↵Vipul A M2015-02-0327-27/+0
| | | | onwards.
* Merge pull request #18791 from Sinjo/consistent-foreign-key-name-generationSean Griffin2015-02-021-2/+2
|\ | | | | Consistent foreign key name generation
| * Generate consistent names for foreign keysChris Sinjakli2015-02-031-2/+2
| |
* | Properly lookup the limit for bigintSean Griffin2015-02-021-0/+5
|/ | | | Fixes #18787.
* Fix validations on child record when record parent has validate: falseeileencodes2015-02-014-5/+50
| | | | | | | | | | | | | | Fixes #17621. This 5 year old (or older) issue causes validations to fire when a parent record has `validate: false` option and a child record is saved. It's not the responsibility of the model to validate an associated object unless the object was created or modified by the parent. Clean up tests related to validations `assert_nothing_raised` is not benefiting us in these tests Corrected spelling of "respects" It's better to use `assert_not_operator` over `assert !r.valid`
* Merge branch 'master' into pr/18316Mingdong Luo2015-01-31100-824/+1366
|\ | | | | | | | | Conflicts: activerecord/CHANGELOG.md
| * Attribute assignment and type casting has nothing to do with columnsSean Griffin2015-01-313-20/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Merge pull request #18512 from vipulnsward/18492-fixtures-with-stiAaron Patterson2015-01-311-7/+14
| |\ | | | | | | Fix STI for fixtures from multi-files
| | * Fixes #18492Vipul A M2015-01-141-7/+14
| | | | | | | | | | | | | | | | | | | | | - Add check for not deleting previously created fixtures, to overcome sti fixtures from multiple files - Added fixtures and fixtures test to verify the same - Fixed wrong fixtures duplicating data insertion in same table
| * | Merge pull request #18700 from nygrenh/better-required-messageAaron Patterson2015-01-311-2/+22
| |\ \ | | | | | | | | Provide a better error message on :required association
| | * | Provide a better error message on :required associationHenrik Nygren2015-01-281-2/+22
| | | | | | | | | | | | | | | | Fixes #18696.
| * | | Remove most type related predicates from `Column`Sean Griffin2015-01-3018-83/+117
| | | | | | | | | | | | | | | | | | | | | | | | Remaining are `limit`, `precision`, `scale`, and `type` (the symbol version). These will remain on the column, since they mirror the options to the `column` method in the schema definition DSL
| * | | Fix a state leak in `autosave_association_test`Sean Griffin2015-01-301-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | The test added in 85465ed3e6c582d25f0c8fafe21f7a2c182c2f67 was passing when the file was run on its own, but failing when the entire suite was run since this test modifies the class and doesn't clean up.
| * | | Always perform validations on nested attribute associationsSean Griffin2015-01-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Collection associations would have already been validated, but singular associations were not. Fixes #18735.
| * | | Post.all.or(anything) == Post.allSean Griffin2015-01-292-5/+5
| | | |
| * | | Fixed AR::Relation#group method when argument is a SQL reserved keywordBogdan Gusiev2015-01-291-0/+5
| | | |
| * | | Don't error when grouped calculations return 0 recordsSean Griffin2015-01-281-0/+5
| | | | | | | | | | | | | | | | Fixes #18717
| * | | Merge Pull Request #16052 Added #or to ActiveRecord::RelationSean Griffin2015-01-282-0/+104
| |\ \ \
| | * | | Bring the implementation of Relation#or up to speedSean Griffin2015-01-282-3/+26
| | | | |
| | * | | Added #or to ActiveRecord::RelationMatthew Draper2015-01-281-0/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Post.where('id = 1').or(Post.where('id = 2')) # => SELECT * FROM posts WHERE (id = 1) OR (id = 2) [Matthew Draper & Gael Muller]
| * | | | Always convert strings to UTF-8, regardless of column type in SQLiteSean Griffin2015-01-281-1/+1
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | All columns which would map to a string primitive need this behavior. Binary has it's own marker type, so it won't go through this conversion. String and text, which need this, will. Fixes #18585.
| * / / Don't redefine autosave association callbacks in nested attrsSean Griffin2015-01-281-0/+10
| |/ / | | | | | | | | | | | | | | | | | | | | | These callbacks will already have been defined when the association was built. The check against `reflection.autosave` happens at call time, not at define time, so simply modifying the reflection is sufficient. Fixes #18704
| * | Remove Relation#bind_paramsSean Griffin2015-01-2713-54/+43
| | | | | | | | | | | | | | | | | | | | | | | | `bound_attributes` is now used universally across the board, removing the need for the conversion layer. These changes are mostly mechanical, with the exception of the log subscriber. Additional, we had to implement `hash` on the attribute objects, so they could be used as a key for query caching.
| * | Use an `Attribute` object to represent a bind valueSean Griffin2015-01-275-25/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The column is primarily used for type casting, which we're trying to separate from the idea of a column. Since what we really need is the combination of a name, type, and value, let's use the object that we already have to represent that concept, rather than this tuple. No consumers of the bind values have been changed, only the producers (outside of tests which care too much about internals). This is *finally* possible since the bind values are now produced from a reasonable number of lcoations.
| * | `WhereClause#predicates` does not need to be publicSean Griffin2015-01-2710-125/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The only place it was accessed was in tests. Many of them have another way that they can test their behavior, that doesn't involve reaching into internals as far as they did. `AssociationScopeTest` is testing a situation where the where clause would have one bind param per predicate, so it can just ignore the predicates entirely. The where chain test was primarly duplicating the logic tested on `WhereClause` directly, so I instead just make sure it calls the appropriate method which is fully tested in isolation.
| * | Move where grouping into `WhereClause`Sean Griffin2015-01-271-0/+33
| | |
| * | Move the `from` bind logic to a `FromClause` classSean Griffin2015-01-261-3/+3
| | | | | | | | | | | | | | | | | | | | | Contrary to my previous commit message, it wasn't overkill, and led to much cleaner code. [Sean Griffin & anthonynavarre]
| * | Remove `Relation#bind_values=`Sean Griffin2015-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The last place that was assigning it was when `from` is called with a relation to use as a subquery. The implementation was actually completely broken, and would break if you called `from` more than once, or if you called it on a relation, which also had its own join clause, as the bind values would get completely scrambled. The simplest solution was to just move it into its own array, since creating a `FromClause` class for this would be overkill.
| * | Remove unused `bind` and `bind!` methods from `Relation`Sean Griffin2015-01-261-9/+0
| | |
| * | Go through normal `where` logic in `AssociationScope`Sean Griffin2015-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the need to duplicate much of the logic in `WhereClause` and `PredicateBuilder`, simplifies the code, removes the need for the connection adapter to be continuously passed around, and removes one place that cares about the internal representation of `bind_values` Part of the larger refactoring to change how binds are represented internally [Sean Griffin & anthonynavarre]
| * | Generate a query that makes sense when testing having clausesSean Griffin2015-01-261-3/+4
| | | | | | | | | | | | | | | | | | PG expects us to not give it nonsenes [Sean Griffin & anthonynavarre]
| * | Change `having_values` to use the `WhereClause` classSean Griffin2015-01-261-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixed an issue where `having` can only be called after the last call to `where`, because it messes with the same `bind_values` array. With this change, the two can be called as many times as needed, in any order, and the final query will be correct. However, once something assigns `bind_values`, that stops. This is because we have to move all of the bind values from the having clause over to the where clause since we can't differentiate the two, and assignment was likely in the form of: `relation.bind_values += other.bind_values` This will go away once we remove all places that are assigning `bind_values`, which is next on the list. While this fixes a bug that was present in at least 4.2 (more likely present going back as far as 3.0, becoming more likely in 4.1 and later as we switched to prepared statements in more cases), I don't think this can be easily backported. The internal changes to `Relation` are non-trivial, anything that involves modifying the `bind_values` array would need to change, and I'm not confident that we have sufficient test coverage of all of those locations (when `having` was called with a hash that could generate bind values). [Sean Griffin & anthonynavarre]
| * | Improve consistency of counter caches updating in memorySean Griffin2015-01-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we made sure that the counter gets updated in memory, we only did it on the has many side. The has many side only does the update if the belongs to cannot. The belongs to side was updated to update the counter cache (if it is able). This means that we need to check if the belongs_to is able to update in memory on the has_many side. We also found an inconsistency where the reflection names were used to grab the association which should update the counter cache. Since reflection names are now strings, this means it was using a different instance than the one which would have the inverse instance set. Fixes #18689 [Sean Griffin & anthonynavarre]
| * | Test association was eager loaded, rather than reaching into internalsSean Griffin2015-01-262-4/+4
| | |
| * | Move flattening records added to an association farther outSean Griffin2015-01-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | There are many ways that things end up getting passed to `concat`. Not all of those entry points called `flatten` on their input. It seems that just about every method that is meant to take a single record, or that splats its input, is meant to also take an array. `concat` is the earliest point that is common to all of the methods which add records to the association. Partially fixes #18689
| * | Remove all references to `where_values` in testsSean Griffin2015-01-2510-62/+62
| | |
| * | Move `where_unscoping` logic over to `WhereClause`Sean Griffin2015-01-251-0/+14
| | |
| * | Move `where.not` logic into `WhereClause`Sean Griffin2015-01-251-0/+26
| | |
| * | Remove all references to `where_values` in association codeSean Griffin2015-01-251-0/+5
| | |
| * | Move where merging logic over to `WhereClause`Sean Griffin2015-01-251-0/+42
| | | | | | | | | | | | | | | | | | This object being a black box, it knows the details of how to merge itself with another where clause. This removes all references to where values or bind values in `Relation::Merger`
| * | Introduce `Relation::WhereClause`Sean Griffin2015-01-252-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way that bind values are currently stored on Relation is a mess. They can come from `having`, `where`, or `join`. I'm almost certain that `having` is actually broken, and calling `where` followed by `having` followed by `where` will completely scramble the binds. Joins don't actually add the bind parameters to the relation itself, but instead add it onto an accessor on the arel AST which is undocumented, and unused in Arel itself. This means that the bind values must always be accessed as `relation.arel.bind_values + relation.bind_values`. Anything that doesn't is likely broken (and tons of bugs have come up for exactly that reason) The result is that everything dealing with `Relation` instances has to know far too much about the internals. The binds are split, combined, and re-stored in non-obvious ways that makes it difficult to change anything about the internal representation of `bind_values`, and is extremely prone to bugs. So the goal is to move a lot of logic off of `Relation`, and into separate objects. This is not the same as what is currently done with `JoinDependency`, as `Relation` knows far too much about its internals, and vice versa. Instead these objects need to be black boxes that can have their implementations swapped easily. The end result will be two classes, `WhereClause` and `JoinClause` (`having` will just re-use `WhereClause`), and there will be a single method to access the bind values of a `Relation` which will be implemented as ``` join_clause.binds + where_clause.binds + having_clause.binds ``` This is the first step towards that refactoring, with the internal representation of where changed, and an intermediate representation of `where_values` and `bind_values` to let the refactoring take small steps. These will be removed shortly.
| * | Merge pull request #18474 from notEthan/pretty_print_inspectSean Griffin2015-01-231-0/+11
| |\ \ | | | | | | | | | | | | pretty_print will use #inspect if a subclass redefines it
| | * | pretty_print will use #inspect if a subclass redefines itEthan2015-01-121-0/+11
| | |/
| * | Fix test failure on PG caused by 7c6f3938dee47f093Sean Griffin2015-01-231-2/+2
| | |
| * | Merge pull request #10776 from bogdan/assign-attributesSean Griffin2015-01-234-6/+6
| |\ \ | | | | | | | | | | | | Extracted attributes assingment from ActiveRecord to ActiveModel