Rails core - Mar 2006 - Confused about the new generator behavior with migrations

Gentle Core Folk:

I''m started trying to work with edge Rails, documenting how
you''d
create a Depot application with them. I''m probably missing something  
here, but as far as I can see, the new generator that creates the  
migration whenever your create a scaffold or model is not  
particularly useful (and in fact is actually counter productive).

Let''s take the scaffolding case. If I run

   script/generate scaffold product admin

I expect it to generate a _form that lets me edit the fields in an  
_existing_ product table.  However, by default, the generator also  
creates a db/migration/xxx_add_products.rb migration. This scaffold  
contains up and down methods with create and drop table method calls.  
But... for me to be using static scaffolds, I _already have_ a  
products table. This migration code will actually fail when I type  
''rake migrate'' , leaving me in an inconsistent state.

So... maybe the idea is to create the scaffold prior to creating the  
table, then add the table definition to the migration, and run rake  
migrate. But, no, that doesn''t work either, as the scaffold generator  
blows up if the table isn''t there. (In fact, it''s worse than
that, as
it also leaves the empty migration file lying around before it exits,  
so I can''t add the table and rerun the generator--I have to run  
destroy first).

So, all things considered, I''d like to suggest that we probably want  
to lose this feature--I just don''t see how it fits into any  
reasonable workflow. It seems to me the workflow is

- create the table with a migration

then, either

- create the model and controller and start hacking, or
- create the scaffold

then

- add migrations, alter the models and controllers
- repeat until IPO


Now, I know you can skip scaffold generation in the generators. But  
surely this should be the default, and the current condition just  
doesn''t seem to be useful in practice.

(On a tangential note, if the model and scaffold generators _do_ have  
to create migrations, they should really be called  
''create_tablename'', not ''add_tablename'',
just to be consistent.)


Dave (who''s just trying to keep up).




_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

> But... for me to be using static scaffolds, I _already have_ a
> products table. This migration code will actually fail when I type
> ''rake migrate'' , leaving me in an inconsistent state.
I agree that''s a catch-22. But the broken part is not migrations, but
rather scaffolding. So let''s think about how we can fix scaffolding in
a way that it doesn''t require the database to exist before running.
Even before this, I''ve been burned by scaffolding requiring the
database to be in place before it would run. The only reason this
haven''t been fixed yet is probably that most of core doesn''t
do
script/generate scaffold all that much.

The auto-migration feature is really nice in a non-scaffolding
workflow, though. The way I use and work with a Rails application is
by creating one model at the time as they''re needed to make the
application work.

So with a shop, I''d start by creating the product model, making it
work, and then moving on to the cart or the order, and every step of
the way making it all work. This is in contrast to, say, creating the
entire schema first, then starting to work on the model or the
controller.

And that''s why the current scaffolding approach is broken. It assumes
that I create my database first while the new model of migrations
encourage a concurrent approach.
>But, no, that doesn''t work either, as the scaffold generator
> blows up if the table isn''t there.
Yup, current scaffolding generator is broken.
> (On a tangential note, if the model and scaffold generators _do_ have
> to create migrations, they should really be called
> ''create_tablename'', not
''add_tablename'', just to be consistent.)
Agree, I''ll rename.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

> The auto-migration feature is really nice in a non-scaffolding
> workflow, though. The way I use and work with a Rails application is
> by creating one model at the time as they''re needed to make the
> application work.
I agree, this is a cool new feature, but I think it should be an
option rather than a default for 1.1. This completely breaks the
principle of least surprise (which rails in general follows). When I
go to generate a model, I expect the model to be created, not model
and migration.

I think the way that migrations were eased in as an option, and now
set as default (overridable in environment.rb) is the way to go.

Additionally, I think a significant amount of people like to design
their dbs first, or in chunks instead of 1 model -> 1 migration. This
is the case for myself.

Does anyone else think that shoving in this default is a bad idea at the moment?

> So let''s think about how we can fix scaffolding in
> a way that it doesn''t require the database to exist before
running.
My first proposal for how to fix this is simply to have
script/generate scaffold return to doing <%= form(@product) %> instead
of writing out the individual lines. Yes, it is kinda neat to have
that, but the pain is not worth it.

This affects page 98 of the book, but that should probably be
rewritten using form_for instead anyway.

And it also doesn''t break any existing applications. It''s just
a new
behavior for new runs of that generator.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

> I agree, this is a cool new feature, but I think it should be an
> option rather than a default for 1.1. This completely breaks the
> principle of least surprise (which rails in general follows). When I
> go to generate a model, I expect the model to be created, not model
> and migration.
Heh. You might want to look up matz''s feelings about PoLS, I think
they apply very well here. (In other words, it breaks _my_ principle
of least surprise not to have migrations come along with models, so
PoLS is inherently personal).
> Additionally, I think a significant amount of people like to design
> their dbs first, or in chunks instead of 1 model -> 1 migration. This
> is the case for myself.
That''s great. We still allow for that. There''s all the
opportunity in
the world to go chasing waterfalls with --skip-migration, but it''s
certainly not an approach that I want to encourage. The current
approach embeds the opinion that developing your application
model-by-model is preferable over chunk-by-chunk, but still allows you
to do the latter at the cost of configuration.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

On Mar 4, 2006, at 18:43, David Heinemeier Hansson wrote:

> The auto-migration feature is really nice in a non-scaffolding
> workflow, though. The way I use and work with a Rails application is
> by creating one model at the time as they''re needed to make the
> application work.
>
> So with a shop, I''d start by creating the product model, making it
> work, and then moving on to the cart or the order, and every step of
> the way making it all work. This is in contrast to, say, creating the
> entire schema first, then starting to work on the model or the
> controller.
>
> And that''s why the current scaffolding approach is broken. It
assumes
> that I create my database first while the new model of migrations
> encourage a concurrent approach.

That''s the way I create them too. I create an empty database, then  
create my first migration. From there, I may generate a migration, or  
create a scaffold (static or dynamic). Then maybe create a migration  
to modify the original table, or create a new table, etc etc.

I think that there''s nothing intrinsically wrong with scaffolding.  
It''s just that in general, decoupled workflows are more flexible than  
ones that do too much at a time.


Dave


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

On Mar 4, 2006, at 19:00, David Heinemeier Hansson wrote:
>> So let''s think about how we can fix scaffolding in
>> a way that it doesn''t require the database to exist before
running.
>
> My first proposal for how to fix this is simply to have
> script/generate scaffold return to doing <%= form(@product) %>
instead
> of writing out the individual lines. Yes, it is kinda neat to have
> that, but the pain is not worth it.
Except... it''s really nice to be able to modify the generated form  
when you''re demoing the application. If you went this approach, why  
not just use a dynamic ''scaffold :product'' line ?

Maybe the step is to break the form stuff out from the rest

I''m not sure what pain you''re trying to save, though.
>
> This affects page 98 of the book, but that should probably be
> rewritten using form_for instead anyway.
Don''t worry about the book: the first half is a total rewrite  
anyway... :)


Dave


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

>
>> Additionally, I think a significant amount of people like to design
>> their dbs first, or in chunks instead of 1 model -> 1 migration.
This
>> is the case for myself.
>
> That''s great. We still allow for that. There''s all the
opportunity in
> the world to go chasing waterfalls with --skip-migration, but it''s
> certainly not an approach that I want to encourage. The current
> approach embeds the opinion that developing your application
> model-by-model is preferable over chunk-by-chunk, but still allows you
> to do the latter at the cost of configuration.

Why not make the generator clever: if there''s no existing table, and  
no existing migration named create_xxx, create the migration.  
Otherwise, don''t create it.







_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

> Except... it''s really nice to be able to modify the generated form
when
> you''re demoing the application. If you went this approach, why not
just use
> a dynamic ''scaffold :product'' line ?
Because generating the scaffold involves so much more than just the
form elements. There are 4-5 actions that all are exposed.

We actually already do this for the list with stuff like:

<% for column in model_name.content_columns %>

So the generated scaffold has a ton more value than just that single
generated form.

I agree that it''s kinda nice, though. I just don''t think its
worth the
pain. Where the pain being that 1) you can''t run scaffold before
setting up database (and it dies mid-air if you do), 2) the flow is
backwards for migrations, 3) the form doesn''t update if you add
additional columns, and 4) the code to make this work is convoluted.
> Why not make the generator clever: if there''s no existing table,
and no existing
> migration named create_xxx, create the migration. Otherwise, don''t
create it.
Oh, that''s interesting. I''d buy a patch for that if it can be
made
cleanly and without other side-effects.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

On Mar 4, 2006, at 19:52, David Heinemeier Hansson wrote:
>
> I agree that it''s kinda nice, though. I just don''t think
its worth the
> pain. Where the pain being that 1) you can''t run scaffold before
> setting up database (and it dies mid-air if you do), 2) the flow is
> backwards for migrations, 3) the form doesn''t update if you add
> additional columns, and 4) the code to make this work is convoluted.

I see that, and (FWIW) I agree. Except...

 From the point of someone who trains newcomers to Rails, the fact  
that the scaffolding generates a form means that they can see what a  
form looks like. When they have to add a column, they can cut and  
paste a 2 lines from the existing form to make the new field work. If  
there''s no form code there, there''s nothing to copy.

So, there''s a kind of breakpoint: during the rock-and-roll phase of  
development, I recommend folks use dynamic scaffolds, so they can  
concentrate of checking their model contains the fields it needs.  
Then, at some point, I suggest they generate a static scaffold. At  
that point, if they add stuff to the schema, they''ll need to edit  
_form.rhtml. But, at this point, they don''t mind this, because  
they''re also interested in changing the look of the forms. To be  
honest, they normally don''t get into the controller code at all.

The other changes at this point will be adding validations and  
behaviors to the models. (This can be problematic, as it breaks the  
unit tests, but that''s a good excuse to explain that tests must be  
kept up to date.)

So, what I''m thinking is that, based on my experience with with  
training side, there''s not must point in static scaffolding with no  
_form.rhtml. Without that feature, we may as well just use dynamic  
scaffolding.

So, is that significant? I think it is. Earlier, I remember folks  
saying that experienced Rails developers don''t often use scaffolding.  
So, if scaffolding is a feature aimed at folks just starting out,  
then perhaps we need to give these folks what they need out of the  
feature.

I don''t think there''s a clear good answer here. In the absence
of
something that''s obviously a lot better, I''d suggest we hold
off
making changes until we have that blinding flash of inspiration. Lets  
drop the migration creation from ''generate scaffold''.


Dave






_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

[slightly off-topic]

FWIW, I''ve been telling my experienced developers learning Rails to
avoid scaffolding. They are un-agile IMO in the sense that they
encourage deviation from proper story-driven development and
test-first programming. Perhaps just me, and certainly a subtle
psychological thing, but it wasn''t until I stopped using scaffolding
that I bothered to really dive deep into the functional testing
features of Rails.

Cheers,
Obie

On 3/4/06, Dave Thomas <dave@pragprog.com> wrote:
>
>
> On Mar 4, 2006, at 19:52, David Heinemeier Hansson wrote:
>
>
>
>
>
> I agree that it''s kinda nice, though. I just don''t think
its worth the
>
> pain. Where the pain being that 1) you can''t run scaffold before
>
> setting up database (and it dies mid-air if you do), 2) the flow is
>
> backwards for migrations, 3) the form doesn''t update if you add
>
> additional columns, and 4) the code to make this work is convoluted.
>
>
> I see that, and (FWIW) I agree. Except...
>
> From the point of someone who trains newcomers to Rails, the fact that the
> scaffolding generates a form means that they can see what a form looks
like.
> When they have to add a column, they can cut and paste a 2 lines from the
> existing form to make the new field work. If there''s no form code
there,
> there''s nothing to copy.
>
> So, there''s a kind of breakpoint: during the rock-and-roll phase
of
> development, I recommend folks use dynamic scaffolds, so they can
> concentrate of checking their model contains the fields it needs. Then, at
> some point, I suggest they generate a static scaffold. At that point, if
> they add stuff to the schema, they''ll need to edit _form.rhtml.
But, at this
> point, they don''t mind this, because they''re also
interested in changing the
> look of the forms. To be honest, they normally don''t get into the
controller
> code at all.
>
> The other changes at this point will be adding validations and behaviors to
> the models. (This can be problematic, as it breaks the unit tests, but
> that''s a good excuse to explain that tests must be kept up to
date.)
>
> So, what I''m thinking is that, based on my experience with with
training
> side, there''s not must point in static scaffolding with no
_form.rhtml.
> Without that feature, we may as well just use dynamic scaffolding.
>
> So, is that significant? I think it is. Earlier, I remember folks saying
> that experienced Rails developers don''t often use scaffolding. So,
if
> scaffolding is a feature aimed at folks just starting out, then perhaps we
> need to give these folks what they need out of the feature.
>
> I don''t think there''s a clear good answer here. In the
absence of something
> that''s obviously a lot better, I''d suggest we hold off
making changes until
> we have that blinding flash of inspiration. Lets drop the migration
creation
> from ''generate scaffold''.
>
>
> Dave
>
>
>
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
>
>
>