I would wager that your issue is with how you are patching migrations to work
and the code you implemented vs a rails core issue. Perhaps the #connection
method below is not enough? A few things that come to mind:
I thought the latest ActiveRecord now solicits all connections for
transactions? Maybe somehow you are creating an orphan pool after rails boots
and connects, which is right before you shim in a new connection? If so,
solving that would involve a deep code dive into a potential area that is not
advertised as configurable.
Have you considered that your workflow may be better served by over riding the
db:migrate task in your own databases.rake and setting either some ENV
variables or hooks to get what you need? Rake allows you to stack tasks, your
would be last in, first run. You could even make your database.yml use ERB and
use said ENV hooks to just make the simple "development" or "test" connection
name go to the migration DBs. If indeed your issue is related to your
implementation, the exploring other options could help.
- Ken
On Apr 20, 2012, at 6:47 AM, Rafael Fernández López wrote:
> Now, in my migrations I have the following:
>
> def connection
> ActiveRecord::Base.establish_connection("migrations_#{Rails.env}").connection
> end
>
> When running "rake db:migrate" I get using the sqlite3 adapter (test and
> development) the following error:
>
> ArgumentError: prepare called on a closed database: rollback transaction
>
> with the following rake trace:
>
> http://pastebin.com/2NvqzEtP
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
