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
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 `incre
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
On Tue, Jan 22, 2013 at 11:45 AM, Brendon Murphy wrote:
> Side note on the updated_at column; the .update_counters method relies on
> .update_all, so it does not bump the updated_at timestamp. This is not
> that unexpected since the column timestamping is handled via the .create
> and .update
Side note on the updated_at column; the .update_counters method relies on
.update_all, so it does not bump the updated_at timestamp. This is not
that unexpected since the column timestamping is handled via the .create
and .update methods for ActiveRecord::Base. While I agree it seems bad to
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,
tho
On Tue, Jan 22, 2013 at 10:39 AM, Pranas 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 return updated value to th
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
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.
Pranas
On Tuesday, January 22, 2013 8:15:16 AM UTC-8, ChuckE wrote:
>
> I understand what you mena. However, how w
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 UT
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
dete
+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:
> https://github.com/
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.
>
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:
> https://github.com/rails/rails/blob/maste
14 matches
Mail list logo
