On Wed, Sep 25, 2013 at 12:37 PM, Roman <[email protected]> wrote:
I have some similar feeling along your words "associations API is only
> partially a finder API", but can't say exactly what is not right. Why
> caching matters, and in case of caching why can't we just return cached
> object or raise?
>
I have the same feeling, it doesn't feel right to me for some reason but
cannot put the finger on it.
Often a cache is something transparent, an optimization that does not alter
the contract, you could remove the cache and reason about the behavior as
you did before. In such a case reasoning about public behavior taking the
cache into account would be suspicious.
In the case of singular associations, the existence of the cache belongs to
the contract. That's why you can do
current_user.company.name = '...'
current_user.company.street = '...'
In this case the cache is not a mere optimization, belongs to the interface.
So my gut feeling says there is something weird in the second call
current_user.company!.name = '...'
current_user.company!.street = '...'
this alternative also looks strange to me
current_user.company!.name = '...'
current_user.company.street = '...'
I am trying with those examples to see how this fits with the existing
API/usage patterns.
In a filter it could make more sense maybe
@company = current_user.company!
but still.
As for singular/plural mismatch, differences in their interfaces are due to
> their nature, they already contain lots of examples of this divergence.
>
Yeah, I believe there is something I don't like about this particular
difference, but this argument/remark is probably weaker.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.
