On 1 February 2011 16:52, Bodaniel Jeanes <[email protected]> wrote:

>  Clarification from my last post: the reason that you might not see the new
> row even from WITHIN the same transaction is because the result of a query
> is essentially cached. I.e. if you took out the first Task.all count from my
> example, the second one WOULD include the new row.
>

This is the case inside a controller, the AR cache is turned on, you can
turn this off for situations like this with

Task.uncached do
  Task.all
  task.save!
  Task.all
end



>
> Daniel N wrote:
>
>
>
> On 1 February 2011 16:36, Chris Mayan <[email protected]> wrote:
>
>> Hi all,
>>
>> Just quick query that's been bugging me this afternoon:
>>
>> Is .save / .save! synchronous?
>> i.e. After I call that line - should the database row be created in
>> the DB before executing the next line?
>>
>> I'm just puzzled as to why step by step debugging, I don't see the DB
>> row created at all even several lines afterwards.
>>
>> Is this because the .save! is inside a transaction block, so Rails on
>> purpose does not actually do any DB actions until the very end of the
>> transaction block?
>> (I always though it committed, and then does a rollback if the
>> transaction fails... meaning I should still see that DB entry in there
>> after the .save line is executed irrespective of the transaction
>> block)
>>
>
>
>  Hi Chris,
>
>  The transactions kinda work that way. Your database server will write to
> the db in a non-commited way while you're inside a transaction block. This
> means that if you're trying to read the database from another connection,
> like the cli or navicat, the data won't be there until the transcaction
> block is all done. It's done this way to prevent reads happening, and then
> the transaction fails. The transaction is only 'pre' written inside the
> transaction block (i.e. it's written as far as that connection is concerned)
> and then when it's done it's finally committed...
>
>  hth
> Daniel
>
>
>
>>
>> Thanks,
>> Chris
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby or Rails Oceania" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<rails-oceania%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/rails-oceania?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<rails-oceania%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Reply via email to