I suspect there is a standard way to handle this issue but I haven''t found it. In my controller create action I have a Transaction. Lets say I''m creating a user object here. def new User.transaction do @user = User.new(params[:user]) #do some stuff set success if no rollback end if success goto success page else render :action => :new end end Now the problem here is when new is rendered @user has an id and it treats it as an edit instead of a new. I could do a the following in the fail block @user = User.new(params[:user]) render :action => :new but the errors are lost (and any changes or associations i created) Or I could nil out the id @user.id = nil render :action => :new It would be nice if the rollback did this for me (sort of like Object Transactions used to but without wiping out the errors and other information)? In my case User has many addresses and many orders so I also need to check and nil their IDs. yuck. What''s the best practice here? Tony
actually making the id nil doesn''t work either. guess it still has created_at and updated_at items. Anyway. Is there a simple way to remedy this issue? On Sep 25, 3:05 pm, Tony <tony.primer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I suspect there is a standard way to handle this issue but I haven''t > found it. > > In my controller create action I have a Transaction. Lets say I''m > creating a user object here. > > def new > User.transaction do > @user = User.new(params[:user]) > #do some stuff set success if no rollback > end > if success > goto success page > else > render :action => :new > end > end > > Now the problem here is when new is rendered @user has an id and it > treats it as an edit instead of a new. > > I could do a the following in the fail block > @user = User.new(params[:user]) > render :action => :new > > but the errors are lost (and any changes or associations i created) > > Or I could nil out the id > @user.id = nil > render :action => :new > > It would be nice if the rollback did this for me (sort of like Object > Transactions used to but without wiping out the errors and other > information)? In my case User has many addresses and many orders so I > also need to check and nil their IDs. yuck. > > What''s the best practice here? > > Tony
On Sep 25, 2:05 pm, Tony <tony.primer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I suspect there is a standard way to handle this issue but I haven''t > found it. > > In my controller create action I have a Transaction. Lets say I''m > creating a user object here. > > def new > User.transaction do > @user = User.new(params[:user]) > #do some stuff set success if no rollback > end > if success > goto success page > else > render :action => :new > end > end > > Now the problem here is when new is rendered @user has an id and it > treats it as an edit instead of a new.That means you saved @user to the database, which you shouldn''t be doing in a new action. The create action is for saving to the database. Jeff purpleworkshops.com> I could do a the following in the fail block > @user = User.new(params[:user]) > render :action => :new > > but the errors are lost (and any changes or associations i created) > > Or I could nil out the id > @user.id = nil > render :action => :new > > It would be nice if the rollback did this for me (sort of like Object > Transactions used to but without wiping out the errors and other > information)? In my case User has many addresses and many orders so I > also need to check and nil their IDs. yuck. > > What''s the best practice here? > > Tony
On Sep 25, 3:44 pm, Jeff <cohen.j...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Sep 25, 2:05 pm, Tony <tony.primer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > I suspect there is a standard way to handle this issue but I haven''t > > found it. > > > In my controller create action I have a Transaction. Lets say I''m > > creating a user object here. > > > def new > > User.transaction do > > @user = User.new(params[:user]) > > #do some stuff set success if no rollback > > end > > if success > > goto success page > > else > > render :action => :new > > end > > end > > > Now the problem here is when new is rendered @user has an id and it > > treats it as an edit instead of a new. > > That means you saved @user to the database, which you shouldn''t be > doing in a new action. The create action is for saving to the > database. >I didn''t save on the new action. The user did a create and after writing to the database there was an issue so I aborted the transaction and sent the user back to the new form (this is the standard practice when there is an error on create). My issue is that my objects now have bogus IDs in them causing the view to treat the object as created. To get around this I now recreate all my objects from the params and run valid? before rendering the new form so any errors will appear (I guess the save would have failed if there were errors on the objects themselves so calling valid is probably not needed).> Jeff > purpleworkshops.com > > > I could do a the following in the fail block > > @user = User.new(params[:user]) > > render :action => :new > > > but the errors are lost (and any changes or associations i created) > > > Or I could nil out the id > > @user.id = nil > > render :action => :new > > > It would be nice if the rollback did this for me (sort of like Object > > Transactions used to but without wiping out the errors and other > > information)? In my case User has many addresses and many orders so I > > also need to check and nil their IDs. yuck. > > > What''s the best practice here? > > > Tony
FYI. It appears there is a ticket on this issue https://rails.lighthouseapp.com/projects/8994/tickets/2991-after-transaction-patch On Sep 25, 4:31 pm, Tony Primerano <tony.primer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Sep 25, 3:44 pm, Jeff <cohen.j...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > On Sep 25, 2:05 pm, Tony <tony.primer...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > I suspect there is a standard way to handle this issue but I haven''t > > > found it. > > > > In my controller create action I have a Transaction. Lets say I''m > > > creating a user object here. > > > > def new > > > User.transaction do > > > @user = User.new(params[:user]) > > > #do some stuff set success if no rollback > > > end > > > if success > > > goto success page > > > else > > > render :action => :new > > > end > > > end > > > > Now the problem here is when new is rendered @user has an id and it > > > treats it as an edit instead of a new. > > > That means you saved @user to the database, which you shouldn''t be > > doing in a new action. The create action is for saving to the > > database. > > I didn''t save on the new action. The user did a create and after > writing to the database there was an issue so I aborted the > transaction and sent the user back to the new form (this is the > standard practice when there is an error on create). > > My issue is that my objects now have bogus IDs in them causing the > view to treat the object as created. > > To get around this I now recreate all my objects from the params and > run valid? before rendering the new form so any errors will appear (I > guess the save would have failed if there were errors on the objects > themselves so calling valid is probably not needed). > > > Jeff > > purpleworkshops.com > > > > I could do a the following in the fail block > > > @user = User.new(params[:user]) > > > render :action => :new > > > > but the errors are lost (and any changes or associations i created) > > > > Or I could nil out the id > > > @user.id = nil > > > render :action => :new > > > > It would be nice if the rollback did this for me (sort of like Object > > > Transactions used to but without wiping out the errors and other > > > information)? In my case User has many addresses and many orders so I > > > also need to check and nil their IDs. yuck. > > > > What''s the best practice here? > > > > Tony > >