@rafaelfranca @neerajdotname can you take a look?

Looks good to me, thanks!

I try to get the User.inspect after I called establish_connection, and it still showed no db connection.

ActiveRecord::Base.establish_connection :development # `adapter: mysql2`
User.inspect #=> User(no database connection)

There was no connection made actually

User.connected? #=> false
ActiveRecord::Base.connected? #=> false

After triggering the connection initialization manually

ActiveRecord::Base.connection
ActiveRecord::Base.connected? #=> true
User.connected? #=> true

or

User.first
User.connected? #=> true

then succeeded to get the User scheme

User.inspect #=> User(id: integer)

It's just a little bit inconvenient to call ActiveRecord::Base.connection to init the connection if I want to get the scheme.

I think it's got nothing to do with Base.inspect but how the connection is made. So I try to patch the ConnectionHandling.establish_connection

def establish_connection(spec = ENV["DATABASE_URL"])
  resolver = ConnectionAdapters::ConnectionSpecification::Resolver.new spec, configurations
  spec = resolver.spec

  unless respond_to?(spec.adapter_method)
    raise AdapterNotFound, "database configuration specifies nonexistent #{spec.config[:adapter]} adapter"
  end

  remove_connection
  connection_handler.establish_connection(self, spec).tap { retrieve_connection } # origin: connection_handler.establish_connection self, spec
end

But I don't think it's a good thing. Any suggestion here?

Thanks,
Hanfei

I can confirm this behavior with the following gist. I don't know ActiveRecord so much but as far as I can see, ActiveRecord is not establishing the connection to the database until you really need it. This leads to an unexpected behavior so I think the fix should be at the ActiveRecord::Base#connected? level ; it should check whether a connection could be triggered so it establishes it and returns the right value Could you give a try to such a patch ?

Before patching ConnectionHandling.establish_connection

ActiveRecord: 4.0.0
Run options: --seed 53183

# Running tests:

F

Finished tests in 0.008572s, 116.6589 tests/s, 233.3178 assertions/s.

  1) Failure:
HasManyDeleteIfTest#test_validations_for_aliased_columns [t.rb:33]:
Failed assertion, no message given.

1 tests, 2 assertions, 1 failures, 0 errors, 0 skips

After patching, it passed.

ActiveRecord: 4.0.0
Run options: --seed 34196

# Running tests:

-- create_table(:users)
D, [2013-10-12T19:01:35.729567 #27174] DEBUG -- :    (0.6ms)  CREATE TABLE "users" ("id" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL)
   -> 0.0041s
.

Finished tests in 0.014912s, 67.0601 tests/s, 201.1803 assertions/s.

1 tests, 3 assertions, 0 failures, 0 errors, 0 skips

I agree but what your patch is doing is that it retrieve the connection in any case. It means that when you call establish_connection, you are connected to the database even if you do not need it and I think that this is unexpected for performances issues but I will wait for feedback before saying more bullshit if I'm wrong. 😄

I agree with you. Not only am I not a ActiveRecord guy, I don't think it's a good approach either. It was just a bad example. :)