foo_count method deprecated for cases when attribute doesn't exist?

rubyonrails-core
1

Sorry this is 2 months late ([5116] and #6225)

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?

If I’m missing something, pls help me. Thanks

2

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(*).

3

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

  1. bar.foos_count with bars.foos_count column and bars.foos_count IS NOT NULL

returns SELECT COUNT(*) with DEPRECATION WARNING

  1. 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

  1. 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

4

puzzled. lemme try rephrasing... and since bar.foo.size appears to behave like bar.foo.count, I'll use foo.count in this example

.count and .size are not the same. size triggers special behavior. You should never called x_count directly.

In any case, this is probably more of a usage question. So let's continue any further discussion on rubyonrails-talk.

5

If x_count isn’t to be used directly… how do I benefit from counter_cache?