Hi all,
Here is my Customer controller''s destroy method:
** def destroy
Customer.find(params[:id]).destroy
redirect_to :action => ''list''
end
It''s stock, untouched scaffold code. When I submit the URL:
http://localhost:3000/customers/destroy/11
The entry in the MySQL database with id 11 is not destroyed. The destroy
method won''t destroy any MySQL entries. Any idea why this is?
- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/b2538293/attachment-0001.html
Tail your development.log to see what SQL is being issued after you
submit. That will enable you to debug.
- dan
--
Dan Kohn <mailto:dan@dankohn.com>
<http://www.dankohn.com/> <tel:+1-415-233-1000>
On Jul 24, 2006, at 9:44 AM, David R. wrote:
> Hi all,
>
> Here is my Customer controller''s destroy method:
>
> def destroy
> Customer.find(params[:id]).destroy
> redirect_to :action => ''list''
> end
>
> It''s stock, untouched scaffold code. When I submit the URL:
>
> http://localhost:3000/customers/destroy/11
>
> The entry in the MySQL database with id 11 is not destroyed. The
> destroy method won''t destroy any MySQL entries. Any idea why this
is?
>
> - David
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/86263500/attachment.html
Is there any output in the development log? On 7/24/06, David R. <lists.david@gmail.com> wrote:> > Hi all, > > Here is my Customer controller''s destroy method: > > ** def destroy > Customer.find(params[:id]).destroy > redirect_to :action => ''list'' > end > > It''s stock, untouched scaffold code. When I submit the URL: > > http://localhost:3000/customers/destroy/11 > > The entry in the MySQL database with id 11 is not destroyed. The destroy > method won''t destroy any MySQL entries. Any idea why this is? > > - David > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/3ae85b18/attachment.html
Thanks for the tip to look into the development log, guys. How handy that
little file is; I fixed my problem. I''ll describe it here so future
Rails
newbies can benefit.
When I looked into the development.log file (located in /railsroot/log/) I
found this little bit:
Processing CustomersController#destroy (for IPADDRESS at 2006-07-14
06:29:52) [GET]
Session ID: 90bcac762fc4f986fcb499be95271082
Parameters: {"action"=>"destroy",
"id"=>"11",
"controller"=>"customers"}
Redirected to http://localhost:3000/customers/list
Filter chain halted as
[#<Proc:0xb78fbea4@/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_controller/verification.rb:64>]
returned false
Completed in 0.00045 (2222 reqs/sec) | DB: 0.00000 (0%) | 302 Found [
http://localhost/customers/destroy/11]
The point to notice is the part that says, "Filter chain halted as
[#<Proc:0xb78fbea4@/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/action_controller/verification.rb:64>]
returned false." This is important because it''s telling me that
the
verification (verification.rb) isn''t being submitted as true.
Basically,
we''re not confirming the destruction of the SQL entry.
My "Destroy" link looked like this:
<%= link_to ''Destroy'', :action =>
''destroy'', :id => @customer %>
When I checked this against the correct scaffold code, I found that the link
should be:
<%= link_to ''Destroy'', { :action =>
''destroy'', :id => @customer }, :confirm
=> ''Are you sure?'', :post => true %>
This way, the application will ask, "Are you sure?" and require a
"Yes" or
"OK" from the user before it will destroy the SQL entry. Because I
wasn''t
including the confirmation bit in the code, the required Yes or OK
didn''t
have a chance to be submitted with the request, so Rails wasn''t
destroying
the entry.
Thanks again!
- David
On 7/24/06, Stephen <sblackstone@gmail.com> wrote:>
> Is there any output in the development log?
>
> On 7/24/06, David R. <lists.david@gmail.com> wrote:
>
> > Hi all,
>
> Here is my Customer controller''s destroy method:
>
> ** def destroy
> Customer.find(params[:id]).destroy
> redirect_to :action => ''list''
> end
>
> It''s stock, untouched scaffold code. When I submit the URL:
>
> http://localhost:3000/customers/destroy/11
>
> The entry in the MySQL database with id 11 is not destroyed. The destroy
> method won''t destroy any MySQL entries. Any idea why this is?
>
> - David
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/4727586c/attachment.html
On Monday, July 24, 2006, at 12:35 PM, David R. wrote:>Thanks for the tip to look into the development log, guys. How handy that >little file is; I fixed my problem. I''ll describe it here so future Rails >newbies can benefit. > >When I looked into the development.log file (located in /railsroot/log/) I >found this little bit: > >Processing CustomersController#destroy (for IPADDRESS at 2006-07-14 >06:29:52) [GET] > Session ID: 90bcac762fc4f986fcb499be95271082 > Parameters: {"action"=>"destroy", "id"=>"11", "controller"=>"customers"} >Redirected to http://localhost:3000/customers/list >Filter chain halted as >[#<Proc:0xb78fbea4@/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/ >action_controller/verification.rb:64>] >returned false >Completed in 0.00045 (2222 reqs/sec) | DB: 0.00000 (0%) | 302 Found [ >http://localhost/customers/destroy/11] > >The point to notice is the part that says, "Filter chain halted as >[#<Proc:0xb78fbea4@/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.1/lib/ >action_controller/verification.rb:64>] >returned false." This is important because it''s telling me that the >verification (verification.rb) isn''t being submitted as true. Basically, >we''re not confirming the destruction of the SQL entry. > >My "Destroy" link looked like this: > ><%= link_to ''Destroy'', :action => ''destroy'', :id => @customer %> > >When I checked this against the correct scaffold code, I found that >the link >should be: > ><%= link_to ''Destroy'', { :action => ''destroy'', :id => @customer }, :confirm >=> ''Are you sure?'', :post => true %> > >This way, the application will ask, "Are you sure?" and require a "Yes" or >"OK" from the user before it will destroy the SQL entry. Because I wasn''t >including the confirmation bit in the code, the required Yes or OK didn''t >have a chance to be submitted with the request, so Rails wasn''t destroying >the entry. > >Thanks again! > >- David > > >On 7/24/06, Stephen <sblackstone@gmail.com> wrote: >> >> Is there any output in the development log? >> >> On 7/24/06, David R. <lists.david@gmail.com> wrote: >> >> > Hi all, >> >> Here is my Customer controller''s destroy method: >> >> ** def destroy >> Customer.find(params[:id]).destroy >> redirect_to :action => ''list'' >> end >> >> It''s stock, untouched scaffold code. When I submit the URL: >> >> http://localhost:3000/customers/destroy/11 >> >> The entry in the MySQL database with id 11 is not destroyed. The destroy >> method won''t destroy any MySQL entries. Any idea why this is? >> >> - David >> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> >> >> _______________________________________________ >> Rails mailing list >> Rails@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> >> > > >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails >Actually the important bit is the '':post=>true''. The confirmation is simply a JS alert but otherwise does nothing. The scaffold is set up to require a ''post'' method for calls to destructive actions, the before_filter that requires the ''post'' is what stopped the action from running. _Kevin www.sciwerks.com -- Posted with http://DevLists.com. Sign up and save your mailbox.