- 07 5月, 2017 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 07 8月, 2016 1 次提交
-
-
由 Xavier Noria 提交于
The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
-
- 20 7月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
`binds` is an array of a query attribute since Active Record 5.0.
-
- 29 2月, 2016 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
Some tests does not work for unprepared statements. Add `if ActiveRecord::Base.connection.prepared_statements` and fix a regex for fix tests failure with `prepared_statements: false`.
-
- 11 6月, 2015 1 次提交
-
-
由 Yves Senn 提交于
-
- 27 12月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
This will allow eager type casting to take place as needed. There doesn't seem to be any particular reason that the `in` statement was forced for single values, and the commit message where it was introduced gives no context. See https://github.com/rails/rails/commit/d90b4e2615e8048fdeffc6dffe3246704adee01f
-
- 14 11月, 2014 1 次提交
-
-
由 Arun Agrawal 提交于
`Computer` class needs to be require See #17217 for more details
-
- 10 4月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 18 1月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 18 5月, 2013 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 26 11月, 2011 1 次提交
-
-
由 Xavier Noria 提交于
Rationale: this is more readable if serveral queries are involved in one call. Also, it will be possible to let AR log EXPLAINs automatically in production mode, where queries are not even around.
-
- 07 11月, 2011 1 次提交
-
-
由 Xavier Noria 提交于
The output in Travis is a bit different. The SQLite documentation (http://www.sqlite.org/eqp.html) warns output may change dramatically between releases. I do not want to mock the result set because I want a real EXPLAIN to happen. I prefer a test that may fail in future releases than a test that may give false positives in future releases.
-
- 06 11月, 2011 1 次提交
-
-
由 Xavier Noria 提交于
This is a first implementation, EXPLAIN is highly dependent on the database and I have made some compromises. On one hand, the method allows you to run the most common EXPLAIN and that's it. If you want EXPLAIN ANALYZE in PostgreSQL you need to do it by hand. On the other hand, I've tried to construct a string as close as possible to the ones built by the respective shells. The rationale is that IMO the user should feel at home with the output and recognize it at first sight. Per database. I don't know whether this implementation is going to work well. Let's see whether people like it.
-