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
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
On 5/24/06, Mike O. [email protected] wrote:
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
That will delete all the files created by the generator, which will
screw with your migrations.
Pat
ruby script/remove model blah?
[email protected]
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
On 5/24/06, Pat M. [email protected] wrote:
try script/destroy
Rails mailing list
[email protected]
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
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
Pat M. wrote:
On 5/24/06, Pat M. [email protected] wrote:
try script/destroy
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/railsJust 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 
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.
On 5/24/06, Mike O. [email protected] 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
[email protected]
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
On Wednesday, May 24, 2006, at 9:22 PM, Pat M. wrote:
Rails mailing list
[email protected]
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
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
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
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