>
> If this is indeed your use case, what I'm advocating here is much
> simpler than that. I just want to be able to increment numeric columns
> in active record without declaring them as counter cache columns.
You should still be able to do that by calling increment_counter or
update_counters class methods, they're generic methods for updating
"counter columns", which mean any numeric column should work, they're not
bound to counter cache columns (even though the filename kinda implies
that).
object.class.increment_counter(:attr_name, object.id)
object.class.update_counters(object.id, :attr_name => 1)
I believe that should work fine for this purpose.
On Wednesday, January 23, 2013 11:28:08 PM UTC-2, ajsharp wrote:
>
> On Wed, Jan 23, 2013 at 4:41 PM, Gabriel Sobrinho
> <gabriel....@gmail.com <javascript:>> wrote:
> >> Since I have to keep a cache column of the paid value for the debt, I
> have 25 workers (sidekiq) that can call `increment!(:paid_value, >>
> paid_value)` and it should keep the total paid value.
> >
> > [SNIP]
> >
> > Yes, I'm thinking about that and seems there is no way to handle this in
> a
> > smart way.
> >
> > Developers can think "from what reason I've incremented by 100 and it
> > incremented by 300" until he figure out that was incremented by other
> > threads too.
> >
>
> Gabriel: I may be confused about your use case, but it sounds like
> your concern is around ensuring that the database client that makes an
> update can rely on the fact that his update was the only one made. Or,
> at least, your application has an "audit" concern, where, you need to
> be able to prove how values were mutated. There are a couple of ways
> to handle this, optimistic locking is one, row-level locks are
> another, or designing a double-entry transaction model is another (so
> you don't rely on locks at all).
>
> If this is indeed your use case, what I'm advocating here is much
> simpler than that. I just want to be able to increment numeric columns
> in active record without declaring them as counter cache columns.
>
> > Maybe some documentation on increment(!)/decrement(!) methods explaining
> > that is not safe to use it concurrently will avoid to think they are.
>
> That'd certainly be helpful, but the same logic applies to any method
> you use. Any sort of CRUD application is subject to concurrent access
> and update problems. Are you simply suggesting documenting
> #increment!/#decrement! because they *don't* behave in the way that
> I'm advocating for in this thread?
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
