On Friday, November 21, 2014 4:23:13 AM UTC-8, [email protected] wrote:
>
> Is there a reason why this is expected behavior?
>
> What's useful in a model instance that fails to represent the current
> status of the table after a transaction fails?
>
Transaction rollbacks should be considered exceptional events, and that's
why they use exceptions. It's impossible to get back to the pre-save state
after the rollback in all cases, as users are allowed to execute arbitrary
code in model save hooks. Just resetting the new flag and resetting the
primary key to nil is not a good idea in general, as it is only a partial
solution, and even that is can be wrong (for example, with a user-specified
primary key, or when you want to reuse the sequence value issued
initially). There are going to be many other similar cases in Sequel where
in process objects will not reflect the database state after a transaction
rollback. In fact, you should always consider in process objects as
possibly stale cached copies of rows in the database.
Even if you wanted to try to handle transaction rollbacks automatically to
reset the @new flag, it wouldn't work correctly when using savepoints:
u = User.new
Sequel::Model.db.transaction do
Sequel::Model.db.transaction(:savepoint=>true, :rollback=>:always) do
u.save
end
u.id
end
Note that Model#exists? will return false after the transaction is rolled
back, so you can always use that to check if a model object actually exists
in the database.
Thanks,
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
