It makes sense!
I have a debt entity in my application and payments this entity can happen
three or more times in parallel (stupid brazilian banks, don't ask me why
they do it).
Since I have to keep a cache column of the paid value for the debt, I have
25 workers (sidekiq) that can call
On Jan 23, 2013, at 4:03 AM, Gabriel Sobrinho wrote:
It makes sense!
I have a debt entity in my application and payments this entity can happen
three or more times in parallel (stupid brazilian banks, don't ask me why
they do it).
Since I have to keep a cache column of the paid value
+1. The same update statement would work for MySQL as well.
Just a small thing: don't forget to take the updated_at timestamp into
account in your patch. Just mentioning in case.
Segunda-feira, 21 de Janeiro de 2013 0:56:37 UTC+1, ajsharp escreveu:
The method is here:
I may be wrong but that's my understanding: #increment happens at instance
level, so it takes into account the current value at that particular
instance, whereas .update_counters is just a straight sql query, so it can
operate using column + value directly. If you want to allow the database to
I understand what you mena. However, how would one handle such an increment
on concurrent threads/processes? You do have to handle the ambiguity
somehow. Delegate the responsibility to the DB sounds reasonable, but some
more inputs would be nice.
Segunda-feira, 21 de Janeiro de 2013 0:56:37
It sounds like an interesting idea but I have some concerns. How about
value stored in AR instance? You wouldn't know what value was saved to
database unless you reload the record.
Pranas
On Tuesday, January 22, 2013 8:15:16 AM UTC-8, ChuckE wrote:
I understand what you mena. However, how
But increment is inherently subject to concurrency issues, and the only way to
safely avoid them is to use a row level lock when incrementing the value, which
presents a whole host of complications of its own.
Cheers,
Alex Sharp
On Jan 22, 2013, at 7:00 AM, Carlos Antonio da Silva
On Tue, Jan 22, 2013 at 10:39 AM, Pranas pranas.kizi...@gmail.com wrote:
It sounds like an interesting idea but I have some concerns. How about
value stored in AR instance? You wouldn't know what value was saved to
database unless you reload the record.
Yea, good point, the DB does not
On second thought, ignore most of what I've said about the updated_at
timestamp. The current method *does* update it (which is your point I
glossed over), so that would need to be carried forward. I still find the
general behavior of things skipping that timestamp a little headscratching,
On Tuesday, January 22, 2013 1:05:50 PM UTC-8, ajsharp wrote:
By bust the cache, do you just mean update the counter?
I was referring to updating the updated_at timestamp, as the default
ActiveRecord #cache_key integrates that column if available to help ease
your cache expiration. In this
Interestingly, ActiveRecord::CounterCache does this the appropriate way.
https://github.com/rails/rails/blob/master/activerecord/lib/active_record/counter_cache.rb#L72
On Sunday, January 20, 2013 6:56:37 PM UTC-5, ajsharp wrote:
The method is here:
Interesting. Hopefully we can get an explanation as to why the increment
methods are not done this way, and if the core team would be open to a patch.
- Alex
On Monday, January 21, 2013 at 6:01 AM, Matt Huggins wrote:
Interestingly, ActiveRecord::CounterCache does this the appropriate way.
12 matches
Mail list logo
