- 25 1月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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`)
-
- 20 1月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
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)
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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`.
-
- 10 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
This is cropping up all over the place. After a brief dive, I'm really not sure why we have `arel.bind_values` at all. A cursory grep didn't reveal where they're actually being assigned (it's definitely in AR, not in Arel). I'd like to dig further into it, as I'm fairly certain we don't actually need it, we just need a way for the predicate builder to communicate merged binds upstream. Fixes #18414
-
- 06 1月, 2015 1 次提交
-
-
由 brainopia 提交于
-
- 05 1月, 2015 1 次提交
- 03 12月, 2014 1 次提交
-
-
由 Melanie Gilman 提交于
-
- 02 12月, 2014 1 次提交
-
-
由 deeeki 提交于
This commit fixes the following case. User.where(User.arel_table[:created_at].lteq(1.year.ago)).unscope(where :created_at)
-
- 30 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
`where_sql` now requires that we pass it an engine. None of the manager classes take an engine in their constructor.
-
由 Sean Griffin 提交于
We never actually make use of it on the table, since we're constructing the select manager manually. It looks like if we ever actually were grabbing it from the table, we're grossly misusing it since it's meant to vary by AR class. Its existence on `Arel::Table` appears to be purely for convenience methods that are never used outside of tests. However, in production code it just complicates construction of the tables on the rails side, and the plan is to remove it from `Arel::Table` entirely. I'm not convinced it needs to live on `SelectManager`, etc either.
-
- 21 11月, 2014 1 次提交
-
-
由 siddharth@vinsol.com 提交于
on the joined assoiciation
-
- 20 11月, 2014 1 次提交
-
-
由 Sam 提交于
-
- 18 11月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Arel handles this for us automatically. Updated tests, as BindParam is no longer a subclass of SqlLiteral. We should remove the second argument to substitute_at entirely, as it's no longer used
-
- 02 11月, 2014 3 次提交
-
-
由 Sean Griffin 提交于
We need to re-order the bind parameters since the AST returned by the relation will have the where statement as the first bp, which breaks on PG.
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
In practical terms, this allows serialized columns and tz aware columns to be used in wheres that go through joins, where they previously would not behave correctly. Internally, this removes 1/3 of the cases where we rely on Arel to perform type casting for us. There were two non-obvious changes required for this. `update_all` on relation was merging its bind values with arel's in the wrong order. Additionally, through associations were assuming there would be no bind parameters in the preloader (presumably because the where would always be part of a join) [Melanie Gilman & Sean Griffin]
-
- 01 11月, 2014 1 次提交
-
-
由 Melanie Gilman 提交于
We end up re-ordering them either way when we construct the Arel AST (in order to deal with rewhere, etc), so we shouldn't bother giving it a number in the first place beforehand.
-
- 29 10月, 2014 1 次提交
-
-
由 Xavier Noria 提交于
The current style for warning messages without newlines uses concatenation of string literals with manual trailing spaces where needed. Heredocs have better readability, and with `squish` we can still produce a single line. This is a similar use case to the one that motivated defining `strip_heredoc`, heredocs are super clean.
-
- 27 10月, 2014 1 次提交
-
-
由 Dan Olson 提交于
-
- 20 10月, 2014 1 次提交
-
-
由 Dan Olson 提交于
-
- 11 9月, 2014 1 次提交
-
-
由 Yves Senn 提交于
[Matthew Draper & Yves Senn] Closes #16860. (pull request to discuss the implementation)
-
- 05 9月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 29 8月, 2014 1 次提交
-
-
由 Godfrey Chan 提交于
Using heredoc would enforce line wrapping to whatever column width we decided to use in the code, making it difficult for the users to read on some consoles. This does make the source code read slightly worse and a bit more error-prone, but this seems like a fair price to pay since the primary purpose for these messages are for the users to read and the code will not stick around for too long.
-
- 19 8月, 2014 1 次提交
-
-
由 Rafael Mendonça França 提交于
If the request parameters are passed to create_with and where they can be used to do mass assignment when used in combination with Relation#create. Fixes CVE-2014-3514 Conflicts: activerecord/lib/active_record/relation/query_methods.rb
-
- 14 8月, 2014 1 次提交
-
-
由 Bogdan Gusiev 提交于
Example: Author.where(posts: { author_id: Author.where(country_id: 1) }).joins(:posts)
-
- 24 5月, 2014 1 次提交
-
-
由 Sergey Alekseev 提交于
It seems that #where! is not designed to be used as a chained where. See initial implementation at 8c2c6051. So, no need to check twice. We should not test #where! https://github.com/rails/rails/pull/15285#discussion_r13018316
-
- 23 5月, 2014 1 次提交
-
-
由 Paul Nikitochkin 提交于
-
- 25 4月, 2014 1 次提交
-
-
由 Yves Senn 提交于
/cc @tenderlove
-
- 22 4月, 2014 1 次提交
-
-
由 Earl J St Sauver 提交于
Fixes #14752 Select mimics the block interface of arrays, but does not mock the block interface for select!. This change moves the api to be a private method, _select!.
-
- 08 4月, 2014 1 次提交
-
-
由 Lauro Caetano 提交于
The reverse_order method was using a flag to control if the order should be reversed or not. Instead of using this variable just build the reverse order inside its proper method. This implementation was leading to an unexpected behavior when using reverse_order and then applying reorder(nil). Example: Before Post.order(:name).reverse_order.reorder(nil) # => SELECT "posts".* FROM "posts" ORDER BY "posts"."id" DESC After Post.order(:name).reverse_order.reorder(nil) # => SELECT "posts".* FROM "posts"
-
- 18 3月, 2014 1 次提交
-
-
由 Earl St Sauver 提交于
The group method also takes an array, however this isn't immediately clear by reading the source since it delegates this method. If you trace it back to the AREL building you can see that it does support an array. Shoutout to @betovelandia for pointing this out.
-
- 17 3月, 2014 1 次提交
-
-
由 Yves Senn 提交于
Closes #14406.
-
- 15 3月, 2014 1 次提交
-
-
由 Steven Harman 提交于
-
- 05 3月, 2014 3 次提交
-
-
由 Yves Senn 提交于
This is a result of the discussion at https://github.com/rails/rails/pull/14263/files#r10291489
-
由 Marcelo Casiraghi 提交于
This behavior has almost no performance impact: String not allowed 66.910000 0.030000 66.940000 ( 67.024976) String allowed 69.360000 0.030000 69.390000 ( 69.503096) Benchmarked with http://git.io/Y0YuRw.
- 01 3月, 2014 1 次提交
-
-
由 Kuldeep Aggarwal 提交于
-