Scaffolding Without Migration? - Porting CakePHP App To RoR

Good day all.

I'm posed with a roadblock on my way to learning and using Ruby on
Rails. From what I've been reading, this has started with version
2.0. The scaffold generation no longer pulls schema from the
database.

I am brand new to RoR (Just got the Agile Web Dev book and just
installed yesterday).

I've been working with CakePHP in the past and have noticed that the
database conventions are quite similar. From what I've been reading,
these migrations serve a good purpose. However, for someone starting
out, it's posing a huge problem. My plan for RoR was to learn while
doing, but I'm kind of stuck right now.

I notice that after running (something, I'm not really sure) it does
pull the schema from the database. Is there anyway to force it to use
this as the initial migration and build on top of that? Is there some
way to bypass this process (at least initially) so I can get stuff out
the door?

I already have a rather large database that I use for CakePHP, which
matches the RoR conventions rather closely (pluralization, foreign
keys, etc).

Is there some sort of scaffolding/migration import?

I would really prefer not having to do all of this manually. It sort
of defeats the purpose, especially for someone getting started.

Any ideas anyone?
ThanX in advance.

Baz L wrote:

Good day all.

Any ideas anyone?
ThanX in advance.

Please check out 'rake --tasks', one of the tasks is 'rake
db:schema:dump' which will take your existing schema and write a file
entitled 'db/schema.rb'. You can then take this file and easily change
it's name to: 'db/migrate/001_initial.rb' and you are off to the races..

prior to doing this make sure your config/database.yaml file is pointing
to the correct db..

ohh.. and please make a dump of your database or make sure you have a
backup prior to doing ANYTHING!!! :slight_smile:

hth

ilan

I just think that I’m confused as to the intended usage of script/generate.

I’ve done a db:schema:dump and set it as the initial migration. But when I do a “script/generate user” from this step, what is supposed to happen?

I would expect (based on all the old tutorials) that it would create the MVCs based on the initial migration? But it doesn’t seem to do that. It creates a user model migration that creates the table with a timestamp only. Nne of the other fields are there.

Please help out this confused newbie.

ThanX in advance all.

Baz wrote:

I would expect (based on all the old tutorials) that it would create the
MVCs based on the initial migration? But it doesn't seem to do that. It
creates a user model migration that creates the table with a timestamp
only.
Nne of the other fields are there.

If you already have a database then you don't need a migration to create
it. If you want a new database based on the old one, then you can use
the schema dump to create a single migration to create all the tables in
the new database. (Point your database.yml file at the old database, do
the dump, point your database.yml file at the new database, then run the
schema dump.)

At this point, whichever situation applies, you have your database
setup. The script/generate script uses various generators to do things.
Run it without arguments to see the usage. This will list available
generators. Of note at this point are:

controller
- creates a controller and its functional test stub
migration
- creates a stub migration file
model
- creates a model and stubs for unit tests, fixtures and also a
migration file
scaffold
- creates a model, its migration file, its controller, and initial
versions of views for CRUD operations as well as the other support files
mentioned above

Since you have the database, you don't need migrations and you're
probably wanting to start with more than basic model or controller
stubs, so use the scaffold generator for now. The generators won't
extract information from the database. In fact, they are primarily
aimed at initial setup so the intended use is to give the generators the
model structure and create the database from that. For example:

script/generate scaffold Sample name:string description:string

This will create a migration to build a "samples" table with "name" and
"description" columns, along with default timestamp columns (you can
edit the migration to remove them if you don't need them). Also, it
will create the model, a controller and the views for the controller
which will refer to your columns.

In your case, you don't *have* to specify the fields since you won't
need the migrations, so for each model you have, just run:

script/generate scaffold Sample
(where "Sample" is replaced with the model name)

You don't want the migration generated so delete it (or it will cause
problems later if you add migrations for new tables, etc). Note,
however, that by not specifying field names, the views will not
reference them so you will have to edit all your views so that they show
all the data you want them to. You'd probably be doing that anyway as
the default views are all pretty basic. (This is a major change in Rails
2 as in previous versions, the views were created to use reflection and
so newly scaffolded views didn't refer to specific columns at all.)

You'll now have a fully scaffolded application. You then need to edit
all your models to set up relationships, names of primary keys (where it
isn't "id"), etc.

Remember that scaffolding is just to provide a bit of structure to help
you build the application, not to be the application. Also look at the
wiki for other generators you can use which may help.

This isn't really more work than you would have to do when starting from
scratch (as then, you still need to think up your models and fields and
specify them in the generators and apply all the migrations).

Mark Bush wrote:

need the migrations, so for each model you have, just run:

script/generate scaffold Sample
(where "Sample" is replaced with the model name)

Sorry, should have mentioned as it may not be obvious, but not all
models will need scaffolding. Only scaffold models where it makes sense
for the application to have controllers. For other models which are
used and referenced without needing controllers, just generate the
models (script/generate model xxx) but still delete the migrations
created.

I’m sorry to keep drawing a reference to CakePHP [The Other Framwork]. However, this is all I have as a reference. So I guess what I’m asking is whether there is a similar way to get this done:

In the other framework, I would :

  1. design a database and point to it.
  2. Use the generator to create my models then add my associations.
  3. Use the generator to generate scaffolds (not sure this is the right term) of the controllers and views.
    These controllers and views would reflect the database structure. There would be a lot of findAll’s, but the flow of the controller was already done. This would be an excellent starting point for my application. It would show the flow of information from Model to Controller to View. Also, it was invaluable when starting the framework. The views were created using all the form helper stuff for the different. But it really helped with learning the framework - especially the associations.

So I guess my final question is: Does RoR provide something similar?

Sorry, hit send by mistake:

With specific reference to the forms in the views, it would extremely benifitial if it would just dump all the info from the table. That way, I would see exactly what syntax needed to be used: when I would need f.text_field or something else. How the form uses select drop downs (belongs to relation) as oppsed to check boxes (boolean), multiple selects (has many), etc.

I’m sort of a “learn by doing” guy, but it’s hard to get started from a clean canvas.

So, does RoR provide this sort of learning environment or is it a sit and read the api and learn the code first?

Baz wrote:

   1. design a database and point to it.
   2. Use the generator to create my models then add my associations.
   3. Use the generator to generate scaffolds (not sure this is the
right
   term) of the controllers and views.

The equivalent in Rails 2 is:

1. design your database (on paper)
2. use the generator to create migrations, models, controllers, views
3. apply the migrations to the database
4. add your associations to your models

So, if you need a model Sample with database table samples which has
columns name & description, run:

script/generate scaffold Sample name:string description:string
rake db:migrate

Now you have:
db/migrate/001_create_samples.rb
which is your migration which you have applied to the database (the
"rake" command will apply all outstanding migrations so you can scaffold
all your models first, then run the migrations in one go).

You also have:
app/models/sample.rb
app/controllers/samples_controller.rb
app/views/samples/edit.html.erb
app/views/samples/index.html.erb
app/views/samples/new.html.erb
app/views/samples/show.html.erb

The controller has actions for listing, adding, editing, and creating
Sample objects. The views will display things for you. If you didn't
specify any fields when you ran the scaffold, then the views will have
no references to fields. The views are *very* basic. You will want to
edit them except in very simple (rare) cases. Note also that the
generated views will not handle any special fields. If a field is a
foreign key to another model, you will just get a text field to input
the ID of the row for the other model. You'll have to handle extracting
the data and creating, say, a select element yourself.

Much appreciated Mark.

I guess the short answer is that, that’s not the way Rails 2.0 works.

I was wondering whether the step: script/generate scaffold Sample name:string description:string
could (somehow) pull the fields from a DB schema/migration (imported from the database), and the answer is no.

Thank you, much appreciated again.