#reload doesn't work to you? Rafael Mendonça França http://twitter.com/rafaelfranca https://github.com/rafaelfranca
On Thu, Feb 28, 2013 at 2:30 AM, Will Bryant <[email protected]> wrote: > The thing that's got worse is having to write different code for > associations vs. relations. Currently #all will behave exactly the same > way on both, which is very useful because you can write code on a model > class that works the same way whether it's working on a global scope or > just an association. > > BTW, the per-request caching mechanism is query caching, which is > different to the loadedness caching that associations do, which is the > reason to_a is not a consistent replacement for #all, and why I want at > least a method that always does a query (#query, for example). > > The query caching mechanism has other effects but it always returns a > fresh set of objects and is also only on when you expect it, so it is > easier to control. > > > On 28/02/2013, at 18:19 , Jarrett Meyer <[email protected]> wrote: > > > http://edgeguides.rubyonrails.org/association_basics.html#controlling-caching > > It looks like clearing the cache and going to the DB is quite easy. I > don't believe your statement is accurate that you can't force a fresh, > enumerated query. And the cache is reset per request, which is a very short > time. The only thing I can think of that would require this kind of > functionality is a database trigger or other out-of-sequence activity. > > > On Feb 27, 2013, at 11:38 PM, Will Bryant <[email protected]> wrote: > > Hi Jarrett, > > As per previous emails, the problem is that you can't now force it to do a > query using any particular method. Associations will cache if you > enumerate them and so will not behave in that simple way. > > Yes we have tests and yes it does show that this kind of change breaks > things. That's why I'm complaining. > > Cheers, > Will > > > On 28/02/2013, at 15:16 , Jarrett Meyer <[email protected]> wrote: > > Most other "enterprise-y" languages (esp. Java+Hibernate, .NET+NHibernate, > .NET+Entity Framework) reinforce deferred execution of queries: the query > is not executed until it is enumerated. This is now the exact same behavior > as those platforms. > > Calling .sum() on an association, before you've enumerated, will alter the > query to perform a SELECT SUM(...). Obviously, this fails on anything that > doesn't exist in the database. If you want to .sum() in memory, you must > enumerate the collection first (calling .ToArray() in .NET will do this). I > don't know if the author of this deferred execution has experience with > these other ORM's, but the behavior is now identical. > > Employee.all vs. Employee.all.to_a is not that big of a deal. And you > should expect breaking changes with a major version number. That's why your > code is covered by tests, right? > > Signed, > An-ex-.NET-developer-turned-Rubyist > > -- > Jarrett Meyer > Email: [email protected] > Web: JarrettMeyer.com <http://jarrettmeyer.com/> > Twitter: @jarrettmeyer <http://twitter.com/jarrettmeyer> > > > On Wed, Feb 27, 2013 at 6:09 PM, Will Bryant <[email protected]>wrote: > >> That's better than nothing, but #all returns a relation now, which is >> half the problem (like when you need to sum methods not columns, for eg.). >> >> >> On 28/02/2013, at 12:00 , Duncan Beevers <[email protected]> wrote: >> >> Or all(true) >> >> >> On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant <[email protected]>wrote: >> >>> >>> On 28/02/2013, at 11:17 , Jon Leighton <[email protected]> wrote: >>> >>> > #reload will always run the query. >>> > >>> > If I'm misunderstanding the use case please provide some examples. >>> >>> Hmm. But you can't run reload on a scope to get an array - it returns a >>> relation, which as per previous emails doesn't behave the same. >>> >>> So are you saying we should use .reload.to_a everywhere instead of #all? >>> >>> That really seems like a worse API than #all and this is a very common >>> operation. Is it really worth changing #all to be nearly useless and have >>> no direct to do that? >>> >>> Could we at least have a method that does this, say "query"? >>> >>> -- >>> 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?hl=en. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> 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?hl=en >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> >> >> -- >> 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?hl=en >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
