puzzled. lemme try rephrasing… and since bar.foo.size appears to behave like bar.foo.count, I’ll use foo.count in this example
bar :has_many :foos
foo belongs_to :bar, :counter_cache => true
these are the behaviors:
returns cached count value managed by counter_cache
- bar.foos_count with bars.foos_count column and bars.foos_count IS NOT NULL
returns SELECT COUNT(*) with DEPRECATION WARNING
- bar.foos_count without “bars.foos_count” column
returns SELECT COUNT(*)
with bars.foos_count column and bars.foos_count IS NULL
4. bar.foos.count with bars.foos_count column and bars.foos_count
IS NOT NULL
5. bar.foos.count with bars.foos_count column and bars.foos_count IS NULL
- bar.foos.count without bars.foos_count column
Let’s say we’re doing things quick and clean, and omitted
foos_count column in the schema (premature optimisation?)
Joe litters his code with bar.foos_count (#2) and live with the awful deprecation warnings; Bob uses bar.foos.count (#6) everywhere and rails gives him a neat log. Times goes by, performance tweaks required, "
bars.foos_count" column is added into the schema. Joe (#1) benefits from caching immediately; Bob (#4) is punished and has to change his code to foos_count.
It seems either #4 should respect
counter_cache values (effectively obsoletes #1 like how find(:all) obsoletes find_all), OR #2 should be accepted without warnings. And if #1 can’t be treated like SELECT COUNT(*) (but faster with caching) in an application, then is counter_cache useful?
Lemme know if I’d misunderstood something? Thanks