the following code is deprecated:
Thread.new { Post.find(1) }.join
It should be changed to close the database connection at the end of
the thread:
Thread.new {
Post.find(1)
Post.connection.close
}.join
Only people who spawn threads in their application code need to worry
about this change.
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.
This reverts commit 0e407a9041, reversing
changes made to 533a9f84b0.
Conflicts:
activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
activerecord/test/cases/migration_test.rb
This commit contains a simple failing test that demonstrates the behaviour we expect, and a fix. When using `becomes` to transform the type of an object, it should retain any error information that was present on the original instance.
Instead of generating association methods directly in the model
class, they are generated in an anonymous module which
is then included in the model class. There is one such module
for each association. The only subtlety is that the
generated_attributes_methods module (from ActiveModel) must
be forced to be included before association methods are created
so that attribute methods will not shadow association methods.
A recent change made to create_table does away with the
need for the block argument. Checking the arity will prevent the
mixing up of the two syntaxes.
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.
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.
