aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord
Commit message (Collapse)AuthorAgeFilesLines
...
| | * | | | Provide a better error message on :required associationHenrik Nygren2015-01-282-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | Fixes #18696.
| * | | | | unify CHANGELOG format. [ci skip]Yves Senn2015-01-311-3/+5
| | | | | |
| * | | | | Remove most type related predicates from `Column`Sean Griffin2015-01-3026-101/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | | | Remove most uses of `Column#cast_type`Sean Griffin2015-01-306-22/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal is to remove the type object from the column, and remove columns from the type casting process entirely. The primary motivation for this is clarity. The connection adapter does not have sufficient type information, since the type we want to work with might have been overriden at the class level. By taking this object from the column, it is easy to mistakenly think that the column object which exists on the connection adapter is sufficient. It isn't. A concrete example of this is `serialize`. In 4.2 and earlier, `where` worked in a very inconsistent and confusing manner. If you passed a single value to `where`, it would serialize it before querying, and do the right thing. However, passing it as part of an array, hash, or range would cause it to not work. This is because it would stop using prepared statements, so the type casting would come from arel. Arel would have no choice but to get the column from the connection adapter, which would treat it as any other string column, and query for the wrong value. There are a handful of cases where using the column object to find the cast type is appropriate. These are cases where there is not actually a class involved, such as the migration DSL, or fixtures. For all other cases, the API should be designed as such that the type is provided before we get to the connection adapter. (For an example of this, see the work done to decorate the arel table object with a type caster, or the introduction of `QueryAttribute` to `Relation`). There are times that it is appropriate to use information from the column to change behavior in the connection adapter. These cases are when the primitive used to represent that type before it goes to the database does not sufficiently express what needs to happen. An example of this that affects every adapter is binary vs varchar, where the primitive used for both is a string. In this case it is appropriate to look at the column object to determine which quoting method to use, as this is something schema dependent. An example of something which would not be appropriate is to look at the type and see that it is a datetime, and performing string parsing when given a string instead of a date. This is the type of logic that should live entirely on the type. The value which comes out of the type should be a sufficiently generic primitive that the adapter can be expected to know how to work with it. The one place that is still using the column for type information which should not be necessary is the connection adapter type caster which is sometimes given to the arel table when we can't find the associated table. This will hopefully go away in the near future.
| * | | | | 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-304-5/+22
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | Collection associations would have already been validated, but singular associations were not. Fixes #18735.
| * | | | Post.all.or(anything) == Post.allSean Griffin2015-01-293-7/+7
| | | | |
| * | | | Fixed AR::Relation#group method when argument is a SQL reserved keywordBogdan Gusiev2015-01-293-13/+27
| | | | |
| * | | | Don't error when grouped calculations return 0 recordsSean Griffin2015-01-282-1/+6
| | | | | | | | | | | | | | | | | | | | Fixes #18717
| * | | | Merge Pull Request #16052 Added #or to ActiveRecord::RelationSean Griffin2015-01-288-1/+166
| |\ \ \ \
| | * | | | Bring the implementation of Relation#or up to speedSean Griffin2015-01-285-44/+48
| | | | | |
| | * | | | Added #or to ActiveRecord::RelationMatthew Draper2015-01-286-1/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-282-12/+7
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-286-1/+20
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2730-130/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `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.
| * | | Merge pull request #18588 from thegcat/patch-1Rafael Mendonça França2015-01-271-1/+1
| |\ \ \ | | | | | | | | | | [ci skip] fix typo still -> will
| | * | | fix typo still cause -> still causesFelix Schäfer2015-01-271-1/+1
| | | | |
| * | | | All subclasses of `Attribute` should be private constantsSean Griffin2015-01-271-1/+1
| | | | |
| * | | | Use an `Attribute` object to represent a bind valueSean Griffin2015-01-2711-41/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | Don't rely on the internal representation of join valuesSean Griffin2015-01-272-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | I'm going to be extracting this logic into a clause class, things need to go through a method and not access the values hash directly.
| * | | | Minor refactorings on `Relation#build_joins`Sean Griffin2015-01-271-26/+13
| | | | | | | | | | | | | | | | | | | | Attempting to grok this code by refactoring it as I go through it.
| * | | | `WhereClause#predicates` does not need to be publicSean Griffin2015-01-2711-126/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | Use the `WhereClause` ast building logic for havingSean Griffin2015-01-271-4/+1
| | | | |
| * | | | Move where grouping into `WhereClause`Sean Griffin2015-01-273-11/+59
| | | | |
| * | | | Unify access to bind values on RelationSean Griffin2015-01-276-21/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bind values can come from four places. `having`, `where`, `joins`, and `from` when selecting from a subquery that contains binds. These need to be kept in a specific order, since the clauses will always appear in that order. Up until recently, they were not. Additionally, `joins` actually did keep its bind values in a separate location (presumably because it's the only case that people noticed was broken). However, this meant that anything accessing just `bind_values` was broken (which most places were). This is no longer possible, there is only a single way to access the bind values, and it includes joins in the proper location. The setter was removed yesterday, so breaking `+=` cases is not possible. I'm still not happy that `joins` is putting it's bind values on the Arel AST, and I'm planning on refactoring it further, but this removes a ton of bug cases.
| * | | | Restore useful documentation removed atRafael Mendonça França2015-01-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3729103e17e00494c8eae76e8a4ee1ac990d3450 [ci skip]
| * | | | Merge pull request #18622 from take/patch-1Abdelkader Boudih2015-01-271-20/+0
| |\ \ \ \ | | | | | | | | | | | | Update ActiveRecord::ModelSchema#table_name= 's doc
| | * | | | Update model_schema.rb [ci skip]Takehiro Adachi2015-01-271-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Overriding these methods may cause unexpected results since "table_name=" does more then just setting the "@table_name". ref: https://github.com/rails/rails/pull/18622#issuecomment-70874358
| * | | | | Move the `from` bind logic to a `FromClause` classSean Griffin2015-01-265-22/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-264-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-262-18/+0
| | | | | |
| * | | | | Remove `Relation#build_where`Sean Griffin2015-01-261-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | All of its uses have been moved to better places
| * | | | | Go through normal `where` logic in `AssociationScope`Sean Griffin2015-01-263-53/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
| * | | | | Ensure the type caster object given to Arel is always marshallableSean Griffin2015-01-261-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Relation will ultimately end up holding a reference to the arel table object, and its associated type caster. If this is a `TypeCaster::Connection`, that means it'll hold a reference to the connection adapter, which cannot be marshalled. We can work around this by just holding onto the class object instead. It's ugly, but I'm hoping to remove the need for the connection adapter type caster in the future anyway. [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-265-10/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-265-7/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-262-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | | | Move method to private sectionCarlos Antonio da Silva2015-01-261-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | It's under private in Active Model as well.
| * | | | | Remove `where_values` and `where_values=`Sean Griffin2015-01-251-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've now removed all uses of them across the board. All logic lives on `WhereClause`.
| * | | | | Correct the implementation for `unscope(:where)`Sean Griffin2015-01-251-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code assumes that non-single-value methods mean multi value methods. That is not the case. We need to change the accessor name, and only assign an array for multi value methods
| * | | | | Move `where_values_hash` over to `WhereClause`Sean Griffin2015-01-252-16/+23
| | | | | |
| * | | | | Remove all references to `where_values` in testsSean Griffin2015-01-2510-62/+62
| | | | | |
| * | | | | Move `where_unscoping` logic over to `WhereClause`Sean Griffin2015-01-253-17/+39
| | | | | |
| * | | | | Remove most references to `where_values` in `QueryMethods`Sean Griffin2015-01-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We're still using it in `where_unscoping`, which will require moving additional logic.
| * | | | | `Relation#Merger` can merge all clause methodsSean Griffin2015-01-251-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | This will make it easy to add `having_clause` and `join_clause` later.
| * | | | | Rename `WhereClause#parts` to `WhereClause#predicates`Sean Griffin2015-01-252-16/+16
| | | | | |
| * | | | | Move `where.not` logic into `WhereClause`Sean Griffin2015-01-253-15/+51
| | | | | |
| * | | | | Move the construction of `WhereClause` objects out of `Relation`Sean Griffin2015-01-252-14/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yes, I know, I called it a factory so I'm basically the worst person ever who loves Java and worships the Gang of Four.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-06 03:55:27 +0000