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
b) If you are doing multiple updates within the same model => wrap a
transaction around it yourself
c) If you are doing multiple updates across various models => wrap a
transaction around it yourself (??is this correct??) and it will be
handled
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?
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.
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.
b) If you are doing multiple updates within the same model => wrap a
transaction around it yourself
Yes.
c) If you are doing multiple updates across various models => wrap a
transaction around it yourself (??is this correct??) and it will be
handled
Yes.
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?
You usually want the record in its dirty state so you can present the
errors
to the user. Object transactions are marginally useful and will be spun
off
into a plugin after Rails 1.2.
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.
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?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.