| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Bind values are no longer a thing, so this is unnecessary.
|
|
|
|
|
|
| |
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`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
See 4d7a62293e148604045a5f78a9d4312e79e90d13 for the reasoning
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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`)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|\
| |
| |
| | |
pretty_print will use #inspect if a subclass redefines it
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | | |
Extracted attributes assingment from ActiveRecord to ActiveModel
|
| | |
| | |
| | |
| | |
| | | |
Minor style changes across the board. Changed an alias to an explicit
method declaration, since the alias will not be documented otherwise.
|
| | |
| | |
| | |
| | |
| | |
| | | |
`ActiveModel::AttributesAssignment`
Allows to use it for any object as an includable module.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | | |
Fixes #18580.
|
| | |
| | |
| | |
| | | |
Fixes #18632
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| | |
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 with `drop_table`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`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.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
```
|
| | |
|
|\ \
| | |
| | | |
Support after_commit callbacks in transactional fixtures
|
| | |
| | |
| | |
| | |
| | |
| | | |
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`.
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add an `:if_exists` option to `drop_table`
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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`.
|
|/ / / |
|
|\ \ \
| | | |
| | | | |
Remove unused accessor
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
Run SQL only if attribute changed for update_attribute method
|
| | | |
| | | |
| | | |
| | | |
| | | | |
- This is based on https://github.com/rails/rails/issues/18400 but
tackling same issue with update_attribute method instead of update method.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
`.` is regexp meta character. It should be escape for `assert_match`
correctly.
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | | |
#assert was used when it should be assert_equal.
|
|/ / |
|
| | |
|
|\ \
| | |
| | | |
Tiny: DRY default limit in ActiveRecord::Type::Integer
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| | |
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.
|