On 28/02/13 05:30, Will Bryant 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.
I don't understand what you mean. Can you give an example of the two different bits of code you have to write? > 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). Again, I don't understand. Please provide before/after code so I can respond to a specific use case. > > > On 28/02/2013, at 18:19 , Jarrett Meyer <[email protected] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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] <mailto:[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] >>>> <mailto:[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] <mailto:[email protected]>> wrote: >>>> >>>>> Or all(true) >>>>> >>>>> >>>>> On Wed, Feb 27, 2013 at 4:25 PM, Will Bryant >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> On 28/02/2013, at 11:17 , Jon Leighton >>>>> <[email protected] <mailto:[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] >>>>> <mailto:rubyonrails-core%[email protected]>. >>>>> To post to this group, send email to >>>>> [email protected] >>>>> <mailto:[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] >>>>> <mailto:[email protected]>. >>>>> To post to this group, send email to >>>>> [email protected] >>>>> <mailto:[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] >>>> <mailto:rubyonrails-core%[email protected]>. >>>> To post to this group, send email to >>>> [email protected] >>>> <mailto:[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] >>>> <mailto:[email protected]>. >>>> To post to this group, send email to >>>> [email protected] >>>> <mailto:[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] >>> <mailto:[email protected]>. >>> To post to this group, send email to >>> [email protected] >>> <mailto:[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] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[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.
