On 28 Feb 2013, at 21:46, Will Bryant <[email protected]> wrote:
> You have to use reload.to_a to work with everything (enumerable methods for > eg.). > > Can we have a method that does this and make it part of the stable API, > please? That's what #all has always done and it's pretty basic functionality. > > > On 1/03/2013, at 01:42 , Rafael Mendonça França <[email protected]> > wrote: > >> #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 >>>>>> Twitter: @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. > > -- > 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.
