Analog to ruby script/generate for removing generated stuff?


#1

All,

If I do ruby script/generate model blah,

is there an easy way for me to remove all of that stuff that got
generated?

Something like:

ruby script/remove model blah?

If it doesn’t exist, is it coming?

Thanks,
Wes


#2

On 24-May-06, at 12:38 PM, Wes G. wrote:

All,

If I do ruby script/generate model blah,

is there an easy way for me to remove all of that stuff that got
generated?

try script/destroy


#3

On 5/24/06, Mike O. removed_email_address@domain.invalid wrote:


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

That will delete all the files created by the generator, which will
screw with your migrations.

Pat


#4

ruby script/remove model blah?
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

rm models/blah.rb
rm test/fixtures/blahs.yml
rm test/unit/blah_test.rb

The generator is nice because it creates a lot of code in addition to
the files. Removing the model is as simple as deleting those three
files. You’ll of course have to remove references elsewhere - but
that certainly should not be done automatically.

Pat


#5

On 5/24/06, Pat M. removed_email_address@domain.invalid wrote:

try script/destroy



Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

“it will only delete the files added by the generate” - which includes
a migration file.

baggio:~/work/test_app pergesu$ ./script/generate model Foo
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/foo.rb
create test/unit/foo_test.rb
create test/fixtures/foos.yml
exists db/migrate
create db/migrate/001_create_foos.rb
baggio:~/work/test_app pergesu$ ./script/destroy model Foo
notempty db/migrate
notempty db
rm db/migrate/001_create_foos.rb
rm test/fixtures/foos.yml
rm test/unit/foo_test.rb
rm app/models/foo.rb

As you can see, the migration got deleted. This is fine if you just
created a model and need to delete it, but I would not recommend
destroying a model that’s got a migration somewhere in the middle.

Just curious - is it really that difficult to rm three files?

Pat


#6

script/destroy shouldn’t mess up any migrations … if you typed
‘script/generate model blah’ then you should type ‘script/destroy model
blah’ and it will only delete the files added by the generate


#7

Pat M. wrote:

On 5/24/06, Pat M. removed_email_address@domain.invalid wrote:

try script/destroy



Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

Just curious - is it really that difficult to rm three files?

Pat

Definitely not that difficult, but when I know I want the shortcut, I’d
like to have it available. You’d be surprised how easy it is to screw
typing 3 rm commands :slight_smile:


#8

On 24-May-06, at 10:12 PM, Pat M. wrote:

Just curious - is it really that difficult to rm three files?

It’s two more (potentially dangerous) commands, yes.


#9

On 5/24/06, Mike O. removed_email_address@domain.invalid wrote:

On 24-May-06, at 10:12 PM, Pat M. wrote:

Just curious - is it really that difficult to rm three files?

It’s two more (potentially dangerous) commands, yes.


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

script/destroy doesn’t work. I’ve shown why - it mucks with the
migration as well. If you rm the wrong file, svn up it. Another
problem with script/destroy is that it doesn’t perform the proper svn
delete commands, so you’ll have to do those manually anyway, negating
the protection from the “dangerous” commands you get from
script/destroy.

Pat


#10

On Wednesday, May 24, 2006, at 9:22 PM, Pat M. wrote:

Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

If you call script/generate or script/destroy with the ‘-c’ flag, it
should do the proper subversion commands as well. I know it works for
generate, but haven’t verified that for destroy.

I also have issues with anything destroying migration files. Those
should be removed manually, if at all.

_Kevin


#11

I have 3 models:

User:
has_many :profiles
has_one :defaultprofile, :class_name => “Profile”,
… # WAY 1 ???
has_one :defaultprofile, :class_name => “Profile”,
:conditions=>“isdefaultprofile=1” # WAY 2

Profile
belongs_to :user
belongs_to :profiletype

Profiletype
has_many :profiles

Basically a user can have many profiles but only ONE is a default. I
have 2 choices on where to store the information on what is a default
profile:

in User, with a field “defaultprofile_id” with profile.id as the key
(WAY 1), or in Profiletype with a field “isdefaultprofile=0|1” (which
also has a user_id=… field) (WAY 2)

WAY 2 works fine

I can’t seem to get WAY 1 to work… I would rather store the fact that
it is a defaultprofile in the User model than in the Profile model as if
I wish to change the defaultprofile as I would not have to worry if I
put the definition in Profiles that there may be more than one profile
that is a defaultprofile.Meaning that with WAY 2 if I wish to change the
default profile of a User I would have to first clear the
isdefaultprofile for all the profiles associated with that user and only
set one to 1. It means, 2 operations. Where as, WAY1 as i see it would
be a simple one operation. User.defaultprofile_id=profile.id

Anyone has any suggestions? I can’t seem to be able to get this “WAY 1”
to work as I intend.

Stephane


#12

Brian H. wrote:

On May 24, 2006, at 11:22 PM, Pat M. wrote:

script/destroy doesn’t work. I’ve shown why - it mucks with the
migration as well. If you rm the wrong file, svn up it.

I’m more or less with you, up to this point. Using script/destroy on
models was a lot simpler before the migration file was auto-generated
as well.

Another problem with script/destroy is that it doesn’t perform the
proper svn
delete commands, so you’ll have to do those manually anyway, negating
the protection from the “dangerous” commands you get from
script/destroy.

This, however, is incorrect. Just like you can do:

script/generate model -c Foo

You can also do:

script/destroy model -c Foo

In fact, I use the -c option all the time. It’s really useful for
cleaning up controllers, if not so great for models, because of the
potential migration hassles.

-Brian

Does -c only work for subversion or could I use it with cvs as well?

Wes


#13

On May 24, 2006, at 11:22 PM, Pat M. wrote:

script/destroy doesn’t work. I’ve shown why - it mucks with the
migration as well. If you rm the wrong file, svn up it.

I’m more or less with you, up to this point. Using script/destroy on
models was a lot simpler before the migration file was auto-generated
as well.

Another problem with script/destroy is that it doesn’t perform the
proper svn
delete commands, so you’ll have to do those manually anyway, negating
the protection from the “dangerous” commands you get from
script/destroy.

This, however, is incorrect. Just like you can do:

script/generate model -c Foo

You can also do:

script/destroy model -c Foo

In fact, I use the -c option all the time. It’s really useful for
cleaning up controllers, if not so great for models, because of the
potential migration hassles.

-Brian