Em 19-02-2013 18:10, Aaron Patterson escreveu:
On Tue, Feb 19, 2013 at 11:51:16AM -0500, Tim Pope wrote:
On Tue, Feb 19, 2013 at 5:27 AM, Aaron Patterson
wrote:
On Mon, Feb 18, 2013 at 10:58:05PM -0500, Tim Pope wrote:
This seems like such an obvious idea that I'm having trouble believing
I'
On Tue, Feb 19, 2013 at 11:51:16AM -0500, Tim Pope wrote:
> On Tue, Feb 19, 2013 at 5:27 AM, Aaron Patterson
> wrote:
> > On Mon, Feb 18, 2013 at 10:58:05PM -0500, Tim Pope wrote:
> >> This seems like such an obvious idea that I'm having trouble believing
> >> I'm the first to think of it. Why not
You are looking at one particular case where the IdentityMap[1] pattern
would be a solution. There are plenty of other cases, including reciprocal
associations (which is currently partly addressed by the :inverse_of option
on association). There was a Ruby Summer of Code project for doing an
Identi
I *think* if you use the :through option in the has_one association will do
what you want.
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On Tue, Feb 19, 2013 at 1:53 PM, ChuckE wrote:
> Yes, explicitly instead of implicitly. I agree with you, and the pu
Yes, explicitly instead of implicitly. I agree with you, and the purpose
here was not to discuss the role of the model layer in Rails. I wanted to
discuss the possible implementation, and using your abstraction, of an
association as a cached version of a cached version of a DB row state, in
whi
On Tue, Feb 19, 2013 at 5:27 AM, Aaron Patterson
wrote:
> On Mon, Feb 18, 2013 at 10:58:05PM -0500, Tim Pope wrote:
>> This seems like such an obvious idea that I'm having trouble believing
>> I'm the first to think of it. Why not take ranges containing
>> Float::INFINITY and translate them to the
Because what is on memory is a cached version of you association. It is
cached to avoid unnecessary queries on the database.
If you want to invalidate the cache you have to tell Rails to do it.
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On Tue, Feb 19
Thanks for the suggestion, that's what I meant by tucking stuff. My point
is, stuff is already somewhere right in memory, why couldn't it be set
right there? I'm exactly trying to avoid the DB roundtrips and the possible
spaghetti code stemming from such a situation.
Terça-feira, 19 de Feverei
If you want to reload the association cache you can pass true as argument.
s.formats(true).select { |f| f.tag == "original" }
Will always get what you want.
Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca
On Tue, Feb 19, 2013 at 12:56 PM, ChuckE wrote:
Hi,
I came across a certain use case that could need some fine tuning. Let's
say I have a song Model. This song is available in many formats. So, the
song has_many formats (mp3, flac, ...). The song also has the original
where the other might have been generated from. So, the song has_one
orig
On Mon, Feb 18, 2013 at 10:58:05PM -0500, Tim Pope wrote:
> This seems like such an obvious idea that I'm having trouble believing
> I'm the first to think of it. Why not take ranges containing
> Float::INFINITY and translate them to the appropriate greater than or
> less than comparisons? Example:
11 matches
Mail list logo
