Makes sense. Thanks!
On Friday, November 21, 2014 2:46:57 PM UTC-2, Jeremy Evans wrote: > > 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.
