Rails - Nov 2006 - foo_count method deprecated for cases when attribute doesn't exist?

Sorry this is 2 months late
([5116<http://dev.rubyonrails.org/changeset/5116#file5>]
and #6225 <http://dev.rubyonrails.org/ticket/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
--
choonkeat


--~--~---------~--~----~------------~-------~--~----~
 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-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
 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-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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
  2. 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
 6. 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


On 11/28/06, DHH <david.heinemeier@gmail.com>
wrote:
>
>
> > 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(*).
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 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-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
 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-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

If x_count isn''t to be used directly... how do I benefit from
counter_cache?

On 12/4/06, DHH <david.heinemeier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> > 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.
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---