aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test
Commit message (Collapse)AuthorAgeFilesLines
* `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-262-1/+10
| | | | | | | | | | | | | | | | | 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
| * | Extracted `ActiveRecord::AttributeAssignment` to ↵Bogdan Gusiev2015-01-234-6/+6
| | | | | | | | | | | | | | | | | | `ActiveModel::AttributesAssignment` Allows to use it for any object as an includable module.
* | | Move integer range validation to never raise on assignmentSean Griffin2015-01-232-15/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given that this was originally added to normalize an error that would have otherwise come from the database (inconsistently), it's more natural for us to raise in `type_cast_for_database`, rather than `type_cast_from_user`. This way, things like numericality validators can handle it instead if the user chooses to do so. It also fixes an issue where assigning an out of range value would make it impossible to assign a new value later. This fixes several vague issues, none of which were ever directly reported, so I have no issue number to give. Places it was mentioned which I can remember: - https://github.com/thoughtbot/shoulda-matchers/blob/9ba21381d7caf045053a81f32df7de2f49687820/lib/shoulda/matchers/active_model/allow_value_matcher.rb#L261-L263 - https://github.com/rails/rails/issues/18653#issuecomment-71197026
* | | Errors raised in `type_cast_for_database` no longer raise on assignmentSean Griffin2015-01-231-0/+17
| | | | | | | | | | | | Fixes #18580.
* | | Don't remove join dependencies in `Relation#exists?`Sean Griffin2015-01-231-0/+6
|/ / | | | | | | Fixes #18632
* | Don't error when invalid json is assigned to a JSON columnSean Griffin2015-01-211-0/+8
| | | | | | | | | | | | | | Keeping with our behavior elsewhere in the system, invalid input is assumed to be `nil`. Fixes #18629.
* | Replace `if exists` with `table_exists?` and drop table statement with ↵Yasuo Honda2015-01-212-3/+3
| | | | | | | | | | | | | | `drop_table` since 'drop table if exists' statement does not always work with some databases such as Oracle. also Oracle drop table statement will not drop sequence objects.
* | Introduce `ActiveRecord::Base#accessed_fields`Sean Griffin2015-01-203-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This method can be used to see all of the fields on a model which have been read. This can be useful during development mode to quickly find out which fields need to be selected. For performance critical pages, if you are not using all of the fields of a database, an easy performance win is only selecting the fields which you need. By calling this method at the end of a controller action, it's easy to determine which fields need to be selected. While writing this, I also noticed a place for an easy performance win internally which I had been wanting to introduce. You cannot mutate a field which you have not read. Therefore, we can skip the calculation of in place changes if we have never read from the field. This can significantly speed up methods like `#changed?` if any of the fields have an expensive mutable type (like `serialize`) ``` Calculating ------------------------------------- #changed? with serialized column (before) 391.000 i/100ms #changed? with serialized column (after) 1.514k i/100ms ------------------------------------------------- #changed? with serialized column (before) 4.243k (± 3.7%) i/s - 21.505k #changed? with serialized column (after) 16.789k (± 3.2%) i/s - 84.784k ```
* | TransactionManager should call rollback recordsArthur Neves2015-01-201-1/+1
| |
* | Merge pull request #18458 from brainopia/fix_after_commit_for_fixturesJeremy Kemper2015-01-203-18/+31
|\ \ | | | | | | Support after_commit callbacks in transactional fixtures
| * | after_commit runs after transactions with non-joinable parentsbrainopia2015-01-163-18/+31
| | | | | | | | | | | | | | | | | | after_commit callbacks run after committing a transaction whose parent is not `joinable?`: un-nested transactions, transactions within test cases, and transactions in `console --sandbox`.
* | | tests, use `drop_table if_exists: true` in our test suite.Yves Senn2015-01-209-13/+13
| | |
* | | Merge pull request #18597 from kamipo/add-if-exists-to-drop-tableYves Senn2015-01-201-0/+11
|\ \ \ | | | | | | | | Add an `:if_exists` option to `drop_table`
| * | | Add an `:if_exists` option to `drop_table`Stefan Kanev2015-01-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If set to `if_exists: true`, it generates a statement like: DROP TABLE IF EXISTS posts This syntax is supported in the popular SQL servers, that is (at least) SQLite, PostgreSQL, MySQL, Oracle and MS SQL Sever. Closes #16366.
* | | | Fix bind value copying from subqueried relationsSean Griffin2015-01-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the old implementation, the bind values were created, and then we search the attributes for `Relation` objects, and merge them. This completely ignores the order that the actual `where` clause will use. If all non-relation where parameters are before the relations, it will work. However, if we query on both a relation and a value, with the value coming second, it breaks. The order of the hash should not affect the final query (especially since hashes being ordered is an implementation detail)
* | | | Whether a column exists or not doesn't affect whether we can use bindsSean Griffin2015-01-191-1/+1
|/ / / | | | | | | | | | | | | | | | Looking through the blame, this logic used to be when we actually created the bind tuple. My guess is that `nil` couldn't be handled there at that time. It can, now.
* | | Merge pull request #18591 from kamipo/remove_unused_accessorSantiago Pastorino2015-01-181-1/+1
|\ \ \ | | | | | | | | Remove unused accessor
| * | | Remove unused accessorRyuta Kamizono2015-01-191-1/+1
| | | |
* | | | Merge pull request #18501 from prathamesh-sonpatki/nosqlSantiago Pastorino2015-01-181-0/+10
|\ \ \ \ | |/ / / |/| | | Run SQL only if attribute changed for update_attribute method
| * | | Run SQL only if attribute changed for update_attribute methodPrathamesh Sonpatki2015-01-181-0/+10
| | | | | | | | | | | | | | | | | | | | - This is based on https://github.com/rails/rails/issues/18400 but tackling same issue with update_attribute method instead of update method.
* | | | Should escape regexp wildcard character `.`Ryuta Kamizono2015-01-1914-34/+34
| | | | | | | | | | | | | | | | | | | | `.` is regexp meta character. It should be escape for `assert_match` correctly.
* | | | Don't calculate in-place changes on attribute assignmentSean Griffin2015-01-181-0/+8
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an attribute is assigned, we determine if it was already marked as changed so we can determine if we need to clear the changes, or mark it as changed. Since this only affects the `attributes_changed_by_setter` hash, in-place changes are irrelevant to this process. Since calculating in-place changes can be expensive, we can just skip it here. I also added a test for the only edge case I could think of that would be affected by this change.
* / / Fix a false assertionYuki Nishijima2015-01-171-1/+1
|/ / | | | | | | #assert was used when it should be assert_equal.
* | Time columns should support time zone aware attributesSean Griffin2015-01-153-3/+55
| | | | | | | | | | | | The types that are affected by `time_zone_aware_attributes` (which is on by default) have been made configurable, in case this is a breaking change for existing applications.
* | Only use the `_before_type_cast` in the form when from user inputSean Griffin2015-01-141-0/+8
| | | | | | | | | | | | While we don't want to change the form input when validations fail, blindly using `_before_type_cast` will cause the input to display the wrong data for any type which does additional work on database values.
* | Don't default to YAML dumping when quoting valuesSean Griffin2015-01-141-8/+5
|/ | | | | | | This behavior exists only to support fixtures, so we should handle it there. Leaving it in `#quote` can cause very subtle bugs to slip through, by things appearing to work when they should be blowing up loudly, such as #18385.
* Stop passing a column to `quote` in testsSean Griffin2015-01-102-6/+7
| | | | | | | I'm planning on deprecating the column argument to mirror the deprecation in [arel]. [arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
* Stop special casing null binary data in loggingSean Griffin2015-01-101-7/+0
| | | | | | There's very little value in logging "<NULL binary data>" instead of just "nil". I'd like to remove the column from the equation entirely, and this case is preventing us from doing so.
* Don't attempt to save dirty attributes which are not persistableSean Griffin2015-01-101-0/+13
| | | | | | | | | | | | | | | | This sets a precident for how we handle `attribute` calls, which aren't backed by a database column. We should not take this as a conscious decision on how to handle them, and this can change when we make `attribute` public if we have better ideas in the future. As the composed attributes API gets fleshed out, I expect the `persistable_attributes` method to change to `@attributes.select(&:persistable).keys`, or some more performant variant there-of. This can probably go away completely once we fully move dirty checking into the attribute objects once it gets moved up to Active Model. Fixes #18407
* Use IO::NULL alwaysNobuyoshi Nakada2015-01-102-2/+2
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-06 00:25:58 +0000