aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | Remove all references to `where_values` in association codeSean Griffin2015-01-256-12/+14
| | | | | |
| * | | | | Remove references to `:bind` in `except`Sean Griffin2015-01-252-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | Bind values are no longer a thing, so this is unnecessary.
| * | | | | Move where merging logic over to `WhereClause`Sean Griffin2015-01-253-40/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-255-11/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Don't access the where values hash directly in through associationsSean Griffin2015-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | See 4d7a62293e148604045a5f78a9d4312e79e90d13 for the reasoning
| * | | | | Don't rely as much on the structure of the values hash in associationsSean Griffin2015-01-252-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The structure of `values[:where]` is going to change, with an intermediate definition of `where_values` to aid the refactoring. Accessing `values[:where]` directly messes with that, signficantly. The array wrapping is no longer necessary, since `where_values` will always return an array.
| * | | | | Fix a typo "devleopment" => "development"Rémy Coutable2015-01-251-1/+1
| | | | | | | | | | | | | | | | | | [ci skip]
| * | | | | Expand the number of types which can use prepared statementsSean Griffin2015-01-243-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow all types which require no additional handling to use prepared statements. Specifically, this will allow for `true`, `false`, `Date`, `Time`, and any custom PG type to use prepared statements. This also revealed another source of nil columns in bind params, and an inconsistency in their use. The specific inconsistency comes from a nested query coming from a through association, where one of the inversed associations is not bi-directional. The stop-gap is to simply construct the column at the site it is being used. This should simply go away on its own once we use `Attribute` to represent them instead, since we already have all of the information we need.
| * | | | | Don't mutate `where_values`Sean Griffin2015-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is to help facilitate future refactorings, as the internal representation is changed. I'm planning on having `where_values` return an array that's computed on call, which means that mutation will have no affect. This is the only remaining place that was mutating (tested by replacing the method with calling `dup`)
| * | | | | Don't rely on relation mutability when building through associationsSean Griffin2015-01-242-19/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, the issue is relying on `where_unscoping` mutating the where values. It does not, however, mutate the bind values, which could cause an error under certain circumstances. This was not exposed by the tests, since the only place which would have been affected is unscoping a boolean, which doesn't go through prepared statements. I had a hard time getting better test coverage to demonstrate the issue. This in turn, caused `merge` to go through proper logic, and try to clear out the binds associated with the unscoped relation, which then exposed a source of `nil` for the columns, as binds weren't expanding `{ "posts.id" => 1 }` to `{ "posts" => { "id" => 1 } }`. This has been fixed. The bulk of `create_binds` needed to be moved to a separate method, since the dot notation should not be expanded recursively. I'm pretty sure this removes a subtle quirk that a ton of code in `Relation::Merger` is working around, and I suspect that code can be greatly simplified. However, unraveling that rats nest is no small task.
| * | | | | Don't duplicate `Relation::VALUE_METHODS` in `Relation::Merger`Sean Griffin2015-01-241-2/+1
| | | | | |
| * | | | | Merge pull request #18474 from notEthan/pretty_print_inspectSean Griffin2015-01-232-0/+16
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | pretty_print will use #inspect if a subclass redefines it
| | * | | | | pretty_print will use #inspect if a subclass redefines itEthan2015-01-122-14/+29
| | | | | | |
| * | | | | | Fix test failure on PG caused by 7c6f3938dee47f093Sean Griffin2015-01-231-2/+2
| | | | | | |
| * | | | | | Merge pull request #10776 from bogdan/assign-attributesSean Griffin2015-01-236-60/+21
| |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Extracted attributes assingment from ActiveRecord to ActiveModel
| | * | | | | | ✂️ and 💅 for #10776Sean Griffin2015-01-231-16/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Minor style changes across the board. Changed an alias to an explicit method declaration, since the alias will not be documented otherwise.
| | * | | | | | Extracted `ActiveRecord::AttributeAssignment` to ↵Bogdan Gusiev2015-01-236-56/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `ActiveModel::AttributesAssignment` Allows to use it for any object as an includable module.
| * | | | | | | Move integer range validation to never raise on assignmentSean Griffin2015-01-234-20/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-234-3/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #18580.
| * | | | | | | Don't remove join dependencies in `Relation#exists?`Sean Griffin2015-01-233-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #18632
| * | | | | | | Use 'public_send' over the 'send' method for object's properties.Santosh Wadghule2015-01-231-2/+2
| |/ / / / / /
| * | | | | | Don't error when invalid json is assigned to a JSON columnSean Griffin2015-01-213-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keeping with our behavior elsewhere in the system, invalid input is assumed to be `nil`. Fixes #18629.
| * | | | | | Merge pull request #18628 from yahonda/if_exists_testingsRafael Mendonça França2015-01-212-3/+3
| |\ \ \ \ \ \ | | |_|/ / / / | |/| | | | | Replace `if exists` with `table_exists?` and drop table with `drop_table`
| | * | | | | 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.
| * | | | | | Change 'a' to 'an' for 'attribute' word [ci skip]Santosh Wadghule2015-01-211-1/+1
| |/ / / / /
| * | | | | Introduce `ActiveRecord::Base#accessed_fields`Sean Griffin2015-01-207-1/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-202-6/+6
| | | | | |
| * | | | | Merge pull request #18458 from brainopia/fix_after_commit_for_fixturesJeremy Kemper2015-01-205-22/+51
| |\ \ \ \ \ | | | | | | | | | | | | | | Support after_commit callbacks in transactional fixtures
| | * | | | | after_commit runs after transactions with non-joinable parentsbrainopia2015-01-165-22/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-205-3/+29
| |\ \ \ \ \ \ | | | | | | | | | | | | | | | | Add an `:if_exists` option to `drop_table`
| | * | | | | | Add an `:if_exists` option to `drop_table`Stefan Kanev2015-01-195-3/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-193-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
| * | | | | | | Move `create_binds` over to the `PredicateBuilder`Sean Griffin2015-01-193-34/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm looking to introduce a `WhereClause` class to handle most of this logic, and this method will eventually move over to there. However, this intermediate refactoring should make that easier to do.
| * | | | | | | Whether a column exists or not doesn't affect whether we can use bindsSean Griffin2015-01-192-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | | | Don't mutate bind values in `Relation`Sean Griffin2015-01-192-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to better facilitate refactoring, most places that mutated `bind_values` have already been removed. One last spot snuck through. Since we're no longer mutating the array, it also does not need to be duped in `initialize_copy`.
| * | | | | | | Fix wording in AR CHANGELOG about time columns change [ci skip]Prathamesh Sonpatki2015-01-191-1/+1
| |/ / / / / /
| * | | | | | 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-183-1/+15
| |\ \ \ \ \ \ | | |/ / / / / | |/| | | | | Run SQL only if attribute changed for update_attribute method
| | * | | | | Run SQL only if attribute changed for update_attribute methodPrathamesh Sonpatki2015-01-183-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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-182-1/+9
| |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Specify correct version in the changelog [ci skip]Sean Griffin2015-01-161-1/+1
| |/ / / /
| * | | | docs, update "How to run Active Record tests". [ci skip]Yves Senn2015-01-151-1/+5
| | | | |
| * | | | Merge pull request #18543 from henrik/integer_limit_or_defaultYves Senn2015-01-151-2/+6
| |\ \ \ \ | | | | | | | | | | | | Tiny: DRY default limit in ActiveRecord::Type::Integer
| | * | | | DRY default limit in ActiveRecord::Type::IntegerHenrik Nyh2015-01-151-2/+6
| | | | | |
| * | | | | Remove incorrect comment in ActiveRecord::Type::ValueHenrik Nyh2015-01-151-2/+1
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Says it's only used for the schema, but they are in fact used for other things. Integer verifies against the limit during casting, and Decimal uses precision during casting. It may be true that scale is only used for the schema.
| * | | | [ci skip] fix typo sill -> stillAditya Kapoor2015-01-151-1/+1
| | | | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-06 06:35:47 +0000