My question is, why is foo_count method deprecated for cases when the foo_count attribute doesn’t exist? Whether the attribute really exist is an implementation detail. Meaning, I should be able to use foo_count always and my code is alright. When situation requires a real column, I’ll add the db column. No code affected.
Why should programmers choose between foo.size or foo_count when implementation changes? Swapping session storage? Nope, code not affected. Good api generally helps me defer implementation decisions with no impact on code. No?
Why should programmers choose between foo.size or foo_count when
implementation changes? Swapping session storage? Nope, code not affected.
Good api generally helps me defer implementation decisions with no impact on
code. No?
They never should. foo.size actually uses foo_count if present,
otherwise it'll do a SELECT COUNT(*).
puzzled. lemme try rephrasing… and since bar.foo.size appears to behave like bar.foo.count, I’ll use foo.count in this example
let
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(*)
3. bar.foos_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?
