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.
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?
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).