Rails - Sep 2006 - transaction question - when does rails handle it itself?

Hi,

Can anyone confirm whether this is correct:

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?

Tks



-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

> 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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/8/06, Greg Hauptmann
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> Can anyone confirm whether this is correct:
>
> 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.

jeremy


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

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?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 9/8/06, johnson_d-j9pdmedNgrk@public.gmane.org
<johnson_d-j9pdmedNgrk@public.gmane.org> wrote:
>
> 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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---