Migration::alter statements?

Rails
1

Hi,

Where to put the execute statements in migration scripts?

e.g, I would like to create a table and add a foreign_key reference.

def self.up
?? execute “alter table …”
create_table :my_table do |t|
t.column :user, :string
end
?? execute “alter table …”
end

Should the execute statement be above the table creation or below the
table
creation? Logically I would like to put it below the table creation.

But sometimes the script is executed from the bottom and sometimes from
the
top.

Is there an order or I miss something?

_Hari

View this message in context:
http://www.nabble.com/Migration%3A%3Aalter-statements----tf2054104.html#a5659538
Sent from the RubyOnRails Users forum at Nabble.com.

2

Nara H. <nhariraj@…> writes:

end
The statements are executed from top to bottom just like any ruby
script. You
must create the table before you can alter it, so put your execute()
with the
foreign key SQL statements after create_table.

-damon

3

Hi Damon,

I was having them on Windows box after the create table, but when I
tried to
migrate the scripts on a Unix box (remote hosting) the scripts
complained
that the table don’t exist and after I moved them before the
create_table it
went fine :frowning:

So I was confused…could this depend on environment?

_Hari

View this message in context:
http://www.nabble.com/Migration%3A%3Aalter-statements----tf2054104.html#a5676643
Sent from the RubyOnRails Users forum at Nabble.com.

4

Nara H. wrote:

Hi Damon,

I was having them on Windows box after the create table, but when I
tried to
migrate the scripts on a Unix box (remote hosting) the scripts
complained
that the table don’t exist and after I moved them before the
create_table it
went fine :frowning:

So I was confused…could this depend on environment?
Not really.

However, if your db is different in one env. vs. another, then I could
see where you’d have different behaviour. If you want to force the
creation, you can add :force => true to the create table and it will
drop your table first before the create. I don’t have any explanation
for why your database on shared hosting would allow you to modify the
table before the create unless it was already there in the first place.
Because otherwise, a SQL error would be obviously be thrown. The table
must have already been there.

Try this in both environments, I guess, and see what happens.

create_table :blah, :force => true do |t|
…
end
execute “blah”

Best,
-damon