Thanks Rob,
I can see that, especially when existing data has to be migrated in
addition to the schema. I'll start using model scoped to the migration
class.
Brett
On Mon 17 Oct 2011 11:52:07 AM PDT, Rob Kaufman wrote:
Hi Brett,
Data loading via db/seeds.rb (and it's accompanying rake task) is a
better practice, but I do agree with Ben that sometimes you just end
up accessing models in your migrations. I solve that by adding the
model definition to the migration namespace and making sure that I'm
always using the scoped version.
Rob
On Mon, Oct 17, 2011 at 11:23, Brett Stewart
<[email protected] <mailto:[email protected]>> wrote:
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
<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]>
<mailto:brett.c.stewart@gmail.__com
<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]>
<mailto:sdruby@googlegroups.__com
<mailto:[email protected]>>
http://groups.google.com/____group/sdruby
<http://groups.google.com/__group/sdruby>
<http://groups.google.com/__group/sdruby
<http://groups.google.com/group/sdruby>>
--
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] <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
