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.