Forum: Ruby on Rails Migration vs create.sql

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Cédric H. (Guest)
on 2006-12-31 00:38
(Received via mailing list)
Hi guys

I've just bought the second edition of Agile Development with Rails .

In the first edition, they say the best way to setup the database is to
use an sql script ( like /config/create.sql ).

But it seems this is deprecated ?

"Do we have to" alway use migration ?

Thanks
Tom M. (Guest)
on 2006-12-31 01:30
(Received via mailing list)
On Dec 21, 2006, at 5:23 PM, Cédric H. wrote:

> I've just bought the second edition of Agile Development with Rails .
>
> In the first edition, they say the best way to setup the database
> is to
> use an sql script ( like /config/create.sql ).

Yes, the book was finished before migrations appeared in Rails, as is
described in the foreword of the new book.

> But it seems this is deprecated ?

Not deprecated, as a SQL creation it's not part of Rails, and
therefore not deprecatable by Rails.

However, many people have deprecated SQL creation scripts in their
Rails application building process, due to migrations' perceived
superiority.

> "Do we have to" alway use migration ?

Nope, you can continue to use the older, more inferior method if you
choose to.

One thing I've found massively helpful, however, is to use a single
creation migration all during development, and only use serial
migrations after the application has gone into production, and then
try to limit to one migration per release.

Not everyone agrees with this procedure, however. :-)

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
Dave T. (Guest)
on 2006-12-31 04:13
(Received via mailing list)
On Dec 21, 2006, at 7:23 PM, Cédric H. wrote:

> I've just bought the second edition of Agile Development with Rails .
>
> In the first edition, they say the best way to setup the database
> is to
> use an sql script ( like /config/create.sql ).
>
> But it seems this is deprecated ?
>
> "Do we have to" alway use migration ?

No.

But it's probably easier to go with the flow.


Dave
Ric Turley (Guest)
on 2006-12-31 17:30
(Received via mailing list)
I have a web site under development without migrations. What is the
easiest
way to create the initial migration classes so I can move forward using
migrations?

Ric Turley
Bill W. (Guest)
on 2006-12-31 17:50
(Received via mailing list)
Hi Ric,

Ric Turley wrote:
> I have a web site under development without migrations. What is the
> easiest way to create the initial migration classes so I can move forward
> using migrations?

I'm in a similar situation myself and am planning to use Recipe 21 -
"Converting to Migration-Based Schemas" in Chad F.'s "Rails
Recipes".

hth,
Bill
Tom M. (Guest)
on 2006-12-31 21:27
(Received via mailing list)
If you run tests, you'll end up with a file, db/schema.rb, which is
largely in migrations format.

Creating an initial migration from that file is very easy indeed.
Bill W. (Guest)
on 2006-12-31 21:47
(Received via mailing list)
Hi Tom,

Tom M. wrote:

> If you run tests, you'll end up with a file, db/schema.rb, which is
> largely in migrations format.
>
> Creating an initial migration from that file is very easy indeed.

In addition to starting to use migrations, which I didn't start out
doing,
I'm also about to start doing automated unit testing, which I also
didn't
start out doing.  Given what you say above, I wonder (in the
unimaginable
event that you found yourself in a similar situation ;-) ) about the
order
in which you'd tackle the two.

Have a safe and happy New Years Eve!
Bill
Tom M. (Guest)
on 2006-12-31 22:25
(Received via mailing list)
On Dec 31, 2006, at 12:45 PM, Bill W. wrote:

> doing, I'm also about to start doing automated unit testing, which
> I also didn't start out doing.  Given what you say above, I wonder
> (in the unimaginable event that you found yourself in a similar
> situation ;-) ) about the order in which you'd tackle the two.

I wouldn't order them at all. Start both today.

Creating a migration will take less than 1 hour, start to finish, if
starting from schema.rb.

This includes time for several false starts, and learning the rake
commands to use the migrations, etc.

Google search for "rake remigrate". It'll be very useful, but may
extend that time to 90 minutes. :-)

Testing is critical, and should be started immediately. There's
*never* a good reason to delay testing for any reason, and once you
use migrations, you'll feel the same way about migrations as well.

Don't look at migrations and testing as a resource drain. Consider
them a productivity boost. Drive in TODAY.

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
Bill W. (Guest)
on 2007-01-01 04:40
(Received via mailing list)
Tom M. wrote:

> I wouldn't order them at all. Start both today.

Hyperbole not appreciated.  With all due respect ...

> Creating a migration will take less than 1 hour, start to finish, if
> starting from schema.rb.

When I started learning Rails I had every intention of using automated
tests
from the beginning.  Spent the better part of a day trying to get just a
couple of functional tests working.  Problems with Rake.  Problem with
the
order of tests and data loading.  No help forthcoming with questions to
the
list.  Etc.  Good news was that the objective of the app I've been
working
on is to output an XML file from the data input during a session.  XML
file
had to be validated using an external, manual process.  So I just cut to
the
chase and built the app using the external validation test.  Not as
comfortable as having an automated suite to build on, but got me to
where I
am with very little if any additional 'cost' over what I'd have had with
the
suite.

> Google search for "rake remigrate".

I"ll do that.  Thanks.  I know there's been a lot of growth over the
last
year.

> It'll be very useful, but may extend that time to 90 minutes. :-)

I've wondered if my earlier experience is, perhaps, a function of the
fact
that I'm using Instant Rails on WinXP.  Doesn't seem to be a pattern
with
the postings.  But maybe I've just missed it.

Bill
Tom M. (Guest)
on 2007-01-01 05:52
(Received via mailing list)
On Dec 31, 2006, at 7:39 PM, Bill W. wrote:
> Tom M. wrote:
>
>> I wouldn't order them at all. Start both today.
>
> Hyperbole not appreciated.  With all due respect ...

Interesting. You asked me a question, and received an honest answer.

You called it hyperbole, and told me my answer is not appreciated.

Happy New Year!

--
-- Tom M., CTO
-- Engine Y., Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)
Cédric H. (Guest)
on 2007-01-01 19:09
(Received via mailing list)
Tom M. a écrit :


> -- Reliability, Ease of Use, Scalability
> -- (866) 518-YARD (9273)


Thank you for you anwser.

It's now the method I use : one migration per table during dev, and
more migrations on production.
Bill W. (Guest)
on 2007-01-01 19:25
(Received via mailing list)
Hi Tom,

Tom M. wrote:
> Interesting. You asked me a question, and received an honest answer.
>
> You called it hyperbole, and told me my answer is not appreciated.

Perhaps I asked my question poorly because your response did not, IMHO,
address it.  Inasmuch as my response obviously offended you, however, I
apologize.

Happy New Year to you too,
Bill
glenn (Guest)
on 2007-01-03 10:37
(Received via mailing list)
Bill,

I'm with Tom here. Given the ease of getting migrations working there
is no reason not to cut over immediately. Tom also justified it with
the fact that both will ultimately prove to be a productivity boost in
the longer term and so it's a false economy to delay any longer.

You'll no doubt appreciate his opinion more once you've actually got it
working.

Glenn
Justin F. (Guest)
on 2007-01-04 06:13
(Received via mailing list)
glenn wrote:
>
> Bill,
>
> I'm with Tom here. Given the ease of getting migrations working there
> is no reason not to cut over immediately. Tom also justified it with
> the fact that both will ultimately prove to be a productivity boost in
> the longer term and so it's a false economy to delay any longer.
>
> You'll no doubt appreciate his opinion more once you've actually got it
> working.

I'd like to support Tom's view too. Out of the two things you asked
about - migrations and automated testing - moving to migrations is a
relatively small change to your development process, and there's
absolutely no reason not to give it a try immediately.

On the testing front, there are two steps you need to consider, and if
you take them the impact on your development process will be profound:

1. Learn the techniques of unit, functional and integration testing with
Rails.

2. Adopt test-driven development. This is a radical change, and I'm not
going to attempt to explain it in an email now (4:45 am UK time). This
article

   http://www.extremeprogramming.org/rules/testfirst.html

is a starting point, and this interview

   http://www.artima.com/intv/testdriven.html

gives more feeling for the impact on the development process. Kent
Beck's book "Test Driven Development: By Example"

http://www.amazon.com/Test-Driven-Development-Addi...

is enlightening - I've never met Kent Beck, but reading the book gave me
the jaw-dropping feeling that Martin F. refers to in the interview
referenced above:

<quote>
I recommend you sit down with somebody whose done test-driven
development, so that you do it pairing with somebody who knows that
style. I think you'd get a much better appreciation of how it works that
way, because it is so very counter-intuitive. Unfortunately we won't
have time to do something like that, but I'd love to do that with you. I
can almost guarantee that you'll say, "What we're going to take that
small of a step? It's not worth going such a small step." And I'll say,
"Just trust me. Do these tiny steps." I've seen it so many times. I
remember watching someone pair program with Kent for the first time.
This guy had read up on XP and was pretty much in favor of it. He was
very positive about XP already. There were times when his jaw was
dropping at the tiny little moves Kent was making. He came out of it
realizing that there is a whole style to test-driven development that he
didn't expect.
</quote>

Have fun!

   Justin F.
This topic is locked and can not be replied to.