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
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. 
No.
But it's probably easier to go with the flow.
Dave
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
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 Fowler's "Rails Recipes".
hth, Bill
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.
Hi Tom,
Tom Mornini 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
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 Mornini 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
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 Mornini a écrit :
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 Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- 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.
Hi Tom,
Tom Mornini 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
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
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
is a starting point, and this interview
artima - Test-Driven Development
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-Addison-Wesley-Signature/dp/0321146530
is enlightening - I've never met Kent Beck, but reading the book gave me the jaw-dropping feeling that Martin Fowler 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 Forder