Starting a new project

Rails
1

When starting a new project, should I build my database in a database
client program, or should i just use database migrations right away?

I’m new on the list btw… Hi :slight_smile:

Christian…

2

Christian Wattengård wrote:

When starting a new project, should I build my database in a database
client program, or should i just use database migrations right away?

Whatever you feel most comfortable with. If you start with a non
migration approach you can always export the schema into a migration
later on (at least the features supported by the schema dumper).
Personally, I always go straight into migrations.

I’m new on the list btw… Hi :slight_smile:

Welcome to the list.

–
Cheers,

  • Jacob A.
3

Christian Wattengård wrote:

When starting a new project, should I build my database in a database
client program, or should i just use database migrations right away?

Start with a test case that fails because a given model does not exist

Then use script/generate model foo to create the model. I suspect it
creates
the migration.

Then migrate with both rake db:migrate and rake RAILS_ENV=test
db:migrate.

–
Phlip
http://www.oreilly.com/catalog/9780596510657/
“Test Driven Ajax (on Rails)”
assert_xpath, assert_javascript, & assert_ajax

4

Hi –

On Thu, 9 Aug 2007, Christian Wattengård wrote:

When starting a new project, should I build my database in a database
client program, or should i just use database migrations right away?

I would at least give yourself the experience of using the migrations
from the beginning in a project, and see what you think. Migrations
have some fragilities, but they’re kind of addictive. Just remember
that migrations and non-migrations don’t mix. The migration system
expects to be in pretty much complete control once it’s in use.

I’m new on the list btw… Hi :slight_smile:

Hi!

David

–

5

Hi –

On Sat, 11 Aug 2007, Phlip wrote:

Christian Wattengård wrote:

When starting a new project, should I build my database in a database
client program, or should i just use database migrations right away?

Start with a test case that fails because a given model does not exist

Then use script/generate model foo to create the model. I suspect it creates
the migration.

It also creates the unit test file for the model. I’m probably
showing my lack of TDD rigor, but I have no problem with creating a
model, letting the framework create the relevant boilerplate files for
me (including the test file), and then starting the process. For one
thing, writing a failing test before generating the model is going to
mean creating a home-made test file, which, if it’s going to fail for
the right reasons, should be identical to the one that the framework
creates. I don’t see any gain in doing that manually.

David

–

6

On 11 Aug, 16:40, [email protected] wrote:

that migrations and non-migrations don’t mix. The migration system
expects to be in pretty much complete control once it’s in use.

Seeing as I have no experience at all in TDD I think that I will skip
that part :wink:
I’ll try both using migrations and the oldschool way I think. :slight_smile:

Christian