transaction question - when does rails handle it itself?

a) If you are an update to a model that has relations, rails
automatically handles updating the relationship table as required and
wraps everything itself in a transaction

Yes. Additionally, any SQL calls happening within a before or after
filter will be governed by the automatic transaction.

b) If you are doing multiple updates within the same model => wrap a
transaction around it yourself

Correct.

c) If you are doing multiple updates across various models => wrap a
transaction around it yourself (??is this correct??) and it will be
handled

Correct.

d) If you want to have your model objects (as well as database) accurate
after a failure/rollback then list the object explicitly as parameters
to the transaction( ) method. "There's a downside to having the
transaction code recover object state
automatically-you can't get to any error information added during
validation" (from AWDR) ==> QUESTION: Is this last point an issue? do
people usually not worry about trying to get their model recovered
correctly? i.e. as it would be re-generated with the next web request
anyway?

Object transactions are going to be deprecated and remove by 2.0.
There's a variety of issues with them and they are very rarely used. If
you still want them post-2.0, you can always add them in yourself. Or
perhaps someone can wrap up a plugin to make it easy.

David Heinemeier Hansson

In my experience, transactions belong at the application layer. J2EE
has taught much of the world that container managed transactions are a
bad (verging on evil) idea except in very small applications.

Rollbacks should return the model objects to their state prior to the
failed transaction, but the application should also gather whatever
information it can from the RDBMS about what caused the transaction to
fail.

In my experience, a failed transaction is either a symptom of
inadequate pre-save edit checks, or a result of a blind dependency on a
program on another system that is identifiable at runtime, and should
be trapped so that a "plain english" error message can be delivered to
the user.

What is the proposed mechanism for giving the application control of
the traqnsaction in Rails 2.0?

In my experience, transactions belong at the application layer. J2EE
has taught much of the world that container managed transactions are a
bad (verging on evil) idea except in very small applications.

Active Record doesn’t do container-managed transactions. The destroy and save callback chains are wrapped in transactions. Otherwise, it’s all you.

Rollbacks should return the model objects to their state prior to the
failed transaction, but the application should also gather whatever
information it can from the RDBMS about what caused the transaction to
fail.

Perhaps this would be sensible elsewhere, but in a typical web app you spit an error and the request is done. The database rollback is sufficient; fancy rollbacks are a roadblock.

In my experience, a failed transaction is either a symptom of
inadequate pre-save edit checks, or a result of a blind dependency on a
program on another system that is identifiable at runtime, and should
be trapped so that a “plain english” error message can be delivered to

the user.

Active Record <3 validation.

What is the proposed mechanism for giving the application control of

the traqnsaction in Rails 2.0?

See the current mechanism and subtract object-level transactions.

jeremy