That wouldn't fix the problem because in the case of two processes
destroying a record at the same time they can both be in the before
callback at the same time. Even after the DELETE SQL is called by one
process, it won't be visible to the other process until the transaction is
committed.
On
To stop messing around with locks, and callbacks if we change the queries
to this:
UPDATE parent_table SET counter_cache = COALESCE(counter_cache, 0) -
(SELECT COUNT(*) FROM table WHERE id = 1) WHERE id = 1
DELETE FROM table WHERE id = 1
This one would not decrement, if record was already delete
I don't think it's really that big of a change. The destroy action happens
inside of a database transactions and the delete SQL will lock the row
being deleted anyway. This would just move the lock up to before the
before_destroy callbacks. This could potentially increase the length of
time a r
I don't think it's reasonable to force pessimistic locks on every single
destroy call, my point is more that in your case it's a work around.
--
Cheers,
Koz
On Wednesday, 17 October 2012 at 7:06 AM, Brian Durand wrote:
> I think adding a pessimistic lock to the destroy method will work. I
I think adding a pessimistic lock to the destroy method will work. I opened
this pull request that locks the record in the database before destroying
it. If the record no longer exists, the callbacks are not called.
https://github.com/rails/rails/pull/7965
This won't work on databases that don'
I've put a stand alone script here that reproduces the issue:
https://gist.github.com/3885509
On Friday, October 12, 2012 1:36:22 PM UTC-7, richard schneeman wrote:
>
> Can you write a public rails app that reproduces this issue? This
> behavior would be undesired and therefore a bug. If we ca
On Saturday, 13 October 2012 at 6:53 AM, Brian Durand wrote:
> I've been looking into consistency problem with association counter caches
> where the counter cache value in the database is not consistent with the
> actual number of records in the association. What I've found is that it is
> from
Can you write a public rails app that reproduces this issue? This behavior
would be undesired and therefore a bug. If we can reproduce and attach that to
an issue it could help the discussion.
--
Richard Schneeman
http://heroku.com
@schneems (http://twitter.com/schneems)
On Friday, Octob
I've been looking into consistency problem with association counter caches
where the counter cache value in the database is not consistent with the
actual number of records in the association. What I've found is that it is
from a concurrency issue where two process try to destroy the same record
