Thanks for the good advice Ben,
I've removed migration containing load data and put that code into load
scripts. Lesson learned.
Brett
On Mon 17 Oct 2011 10:18:39 AM PDT, Ben Hughes wrote:
Although everyone breaks this rule, it's generally bad practice to use
model references in your migration files, precisely because of the
problem you're now running into. Migrations are supposed to affect
*schema*, and you don't want schema cross-dependent on your models and
the state of those models in your source code. You want your
migrations to always be idempotent given a particular schema revision.
So for example if you really want to update data in a migration
(leaving aside whether this is good practice or not - that's a
separate debate):
The wrong way:
Customer.update_all :field => 1
(A) right way:
ActiveRecord::Base.connection.execute("UPDATE customers SET field = 1")
Assuming you don't actually want to change the semantics of your
migration scripts, what I would probably do is modify the migration to
not depend on that model and instead directly operate on the schema.
But then again depending on what you're doing it might make more sense
to extract this stuff out as seed data or some other loader anyways,
but that's hard to judge without knowing the specific circumstances.
Another option instead of (3) is to define a stub ActiveRecord model
*within* your migration file, so it's in scope only for your
migration. See the example here:
http://ketan.padegaonkar.name/2010/11/20/using-models-in-rails-migrations.html
Ben
On Mon, Oct 17, 2011 at 10:08 AM, Brett Stewart
<[email protected] <mailto:[email protected]>> wrote:
I have a situation where I've renamed a table and removed a model
after
many migrations. In prior migrations, the model is used to save
default
data to db. I have a new developer who want to run migrations for the
first time, but now an error occurs because the model which sets the
data has been removed from the source.
The list of options I've thought of:
1) give SQL dump of db so he can start from current state
2) Remove migrations which set data and place into a script (and
Capistrano recipe)
3) Add model back to source, and deprecate (starting to smell bad)
Question: What is the best method for adding a deprecation warning
on an entire model and not just it's methods?
I'm tempted to use the following
----
require 'active_support/deprecation'
class B< ActiveRecord::Base
def initialize(attributes = nil)
self
end
deprecate :initialize
end
----
This probably won't work because of addition of validations after
future migrations
4) modify migrations (smells really bad)
The system has not been put into production yet, but this is not a
maintainable solution.
Thanks in advance for help,
Brett
--
SD Ruby mailing list
[email protected] <mailto:[email protected]>
http://groups.google.com/__group/sdruby
<http://groups.google.com/group/sdruby>
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
--
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
