I am using fragment caching to render a select box where the contents of the select box comes from a lengthy db query. A simplified example showing the problem is <% cache ''select_box'' do %> <%= f.collection_select :variety_id, @varieties, :id, :name %> <% end %> where @varieties is setup in the controller. Unfortunately this does not achieve the desired result as the query is run even when the select is picked up from the cache. To get the full benefit I have to remove @varieties = Variety.all from the controller and use <% cache ''select_box'' do %> <%= f.collection_select :variety_id, Variety.all, :id, :name %> <% end %> but this breaks the rule that one should not access the model from the view. Is there a good solution to this problem? Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 Mar 2011, at 16:06, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> I am using fragment caching to render a select box where the contents > of the select box comes from a lengthy db query. A simplified example > showing the problem is > <% cache ''select_box'' do %> > <%= f.collection_select :variety_id, @varieties, :id, :name %> > <% end %> > where @varieties is setup in the controller. Unfortunately this does > not achieve the desired result as the query is run even when the > select is picked up from the cache. > > To get the full benefit I have to remove @varieties = Variety.all from > the controller and use > <% cache ''select_box'' do %> > <%= f.collection_select :variety_id, Variety.all, :id, :name %> > <% end %> > but this breaks the rule that one should not access the model from the > view. Is there a good solution to this problem?In the controller, you can check for the presence of the cached fragment using the read_fragment method. Then, only run the database query if the fragment isn''t cached yet. Chris -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 March 2011 18:22, Chris Mear <chrismear-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 8 Mar 2011, at 16:06, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > >> I am using fragment caching to render a select box where the contents >> of the select box comes from a lengthy db query. A simplified example >> showing the problem is >> <% cache ''select_box'' do %> >> <%= f.collection_select :variety_id, @varieties, :id, :name %> >> <% end %> >> where @varieties is setup in the controller. Unfortunately this does >> not achieve the desired result as the query is run even when the >> select is picked up from the cache. >> >> To get the full benefit I have to remove @varieties = Variety.all from >> the controller and use >> <% cache ''select_box'' do %> >> <%= f.collection_select :variety_id, Variety.all, :id, :name %> >> <% end %> >> but this breaks the rule that one should not access the model from the >> view. Is there a good solution to this problem? > > In the controller, you can check for the presence of the cached fragment using the read_fragment method. Then, only run the database query if the fragment isn''t cached yet.That''s a great idea, in fact it is probably fragment_exists?(''select_box'') that I want to use. I will give it a go. Thanks Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Jim Ruther Nill
2011-Mar-09 00:37 UTC
Re: Fragment caching and not accessing model from view
On Wed, Mar 9, 2011 at 12:06 AM, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> I am using fragment caching to render a select box where the contents > of the select box comes from a lengthy db query. A simplified example > showing the problem is > <% cache ''select_box'' do %> > <%= f.collection_select :variety_id, @varieties, :id, :name %> > <% end %> > where @varieties is setup in the controller. Unfortunately this does > not achieve the desired result as the query is run even when the > select is picked up from the cache. > >are you just using .all or a complex query? Because if you''re using a complex query and you''re using rails3, then just remove the .all in the complex query in the controller so that it won''t run the query. I think it just saves the relation to the @varieties variable and won''t run the query until a method is called on the variable such .each or .collect.> To get the full benefit I have to remove @varieties = Variety.all from > the controller and use > <% cache ''select_box'' do %> > <%= f.collection_select :variety_id, Variety.all, :id, :name %> > <% end %> > but this breaks the rule that one should not access the model from the > view. Is there a good solution to this problem? > > Colin > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- ------------------------------------------------------------- visit my blog at http://jimlabs.heroku.com -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Tue, Mar 8, 2011 at 4:06 PM, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> I am using fragment caching to render a select box where the contents > of the select box comes from a lengthy db query. A simplified example > showing the problem is > <% cache ''select_box'' do %> > <%= f.collection_select :variety_id, @varieties, :id, :name %> > <% end %> > where @varieties is setup in the controller. Unfortunately this does > not achieve the desired result as the query is run even when the > select is picked up from the cache. > > To get the full benefit I have to remove @varieties = Variety.all from > the controller and use > <% cache ''select_box'' do %> > <%= f.collection_select :variety_id, Variety.all, :id, :name %> > <% end %> > but this breaks the rule that one should not access the model from the > view. Is there a good solution to this problem? > > Yes, you are right. One should not access the model from the view.Create a method in the model, say def self.your_method_name your_query end and then you can access the model in your view, using the method you just defined in the model.> Colin > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Michael Pavling
2011-Mar-09 09:32 UTC
Re: Fragment caching and not accessing model from view
On 9 March 2011 09:19, Jatin kumar <jatinkumar.nitk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Tue, Mar 8, 2011 at 4:06 PM, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> <%= f.collection_select :variety_id, Variety.all, :id, :name %> >> > Yes, you are right. One should not access the model from the view. > > Create a method in the model, say > > def self.your_method_name > your_query > end > > and then you can access the model in your view, using the method you just > defined in the model.I don''t see how: <%= f.collection_select :variety_id, Variety.all, :id, :name %> is different from : <%= f.collection_select :variety_id, Variety.your_method_name, :id, :name %> ?:-/ If you say in one breath "don''t access models from the view" and then in the next create a model class method... how''s that different from using the ".all" class method? (btw I agree that one shouldn''t access the model from the view - I''m just querying that your suggestion may not remove this MVC-breaking practice in this instance) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Frederick Cheung
2011-Mar-09 10:27 UTC
Re: Fragment caching and not accessing model from view
On Mar 8, 4:06 pm, Colin Law <clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> I am using fragment caching to render a select box where the contents > of the select box comes from a lengthy db query. A simplified example > showing the problem is > <% cache ''select_box'' do %> > <%= f.collection_select :variety_id, @varieties, :id, :name %> > <% end %> > where @varieties is setup in the controller. Unfortunately this does > not achieve the desired result as the query is run even when the > select is picked up from the cache. >One take on this was interlock ( https://github.com/fauna/interlock ) although i haven''t used it personally (and looks like it hasn''t been touched in a while) Fred -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 8 March 2011 20:04, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 8 March 2011 18:22, Chris Mear <chrismear-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> On 8 Mar 2011, at 16:06, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> >>> I am using fragment caching to render a select box where the contents >>> of the select box comes from a lengthy db query. A simplified example >>> showing the problem is >>> <% cache ''select_box'' do %> >>> <%= f.collection_select :variety_id, @varieties, :id, :name %> >>> <% end %> >>> where @varieties is setup in the controller. Unfortunately this does >>> not achieve the desired result as the query is run even when the >>> select is picked up from the cache. >>> >>> To get the full benefit I have to remove @varieties = Variety.all from >>> the controller and use >>> <% cache ''select_box'' do %> >>> <%= f.collection_select :variety_id, Variety.all, :id, :name %> >>> <% end %> >>> but this breaks the rule that one should not access the model from the >>> view. Is there a good solution to this problem? >> >> In the controller, you can check for the presence of the cached fragment using the read_fragment method. Then, only run the database query if the fragment isn''t cached yet. > > That''s a great idea, in fact it is probably > fragment_exists?(''select_box'') that I want to use. I will give it a > go.Just to confirm that, in the controller, @varieties = Variety.all if !fragment_exist?( ''select_box'' ) does the job. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 9 March 2011 00:37, Jim Ruther Nill <jvnill-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > On Wed, Mar 9, 2011 at 12:06 AM, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> >> I am using fragment caching to render a select box where the contents >> of the select box comes from a lengthy db query. A simplified example >> showing the problem is >> <% cache ''select_box'' do %> >> <%= f.collection_select :variety_id, @varieties, :id, :name %> >> <% end %> >> where @varieties is setup in the controller. Unfortunately this does >> not achieve the desired result as the query is run even when the >> select is picked up from the cache. >> > > are you just using .all or a complex query? Because if you''re using a > complex > query and you''re using rails3, then just remove the .all in the complex > query > in the controller so that it won''t run the query. I think it just saves > the > relation to the @varieties variable and won''t run the query until a method > is > called on the variable such .each or .collect.I had noticed that some queries don''t get run till the collection is used, whereas others seem to run immediately. I did not find documented exactly how to tell in advance which will get run and which won''t. I wonder whether using a named scope would guarantee delayed operation. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Frederick Cheung
2011-Mar-09 11:54 UTC
Re: Fragment caching and not accessing model from view
On Mar 9, 11:25 am, Colin Law <clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> I had noticed that some queries don''t get run till the collection is > used, whereas others seem to run immediately. I did not find > documented exactly how to tell in advance which will get run and which > won''t. I wonder whether using a named scope would guarantee delayed > operation.(named) scopes are lazily evaluated. Fred -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
anu priya
2011-Mar-09 11:58 UTC
Re: Re: Fragment caching and not accessing model from view
hi fred, Ya i can get your point,but in rails we will use scope instead of named_scope.If i try rake task separately means its working. On Wed, Mar 9, 2011 at 5:24 PM, Frederick Cheung <frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > On Mar 9, 11:25 am, Colin Law <clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > > I had noticed that some queries don''t get run till the collection is > > used, whereas others seem to run immediately. I did not find > > documented exactly how to tell in advance which will get run and which > > won''t. I wonder whether using a named scope would guarantee delayed > > operation. > > (named) scopes are lazily evaluated. > > Fred > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
anu priya
2011-Mar-09 11:59 UTC
Re: Re: Fragment caching and not accessing model from view
hi, I also have a query how to integrate rake task with cronjobs any idea how to use with example. Anu On Wed, Mar 9, 2011 at 5:28 PM, anu priya <anuhema1989-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> hi fred, > > Ya i can get your point,but in rails we will use scope instead of > named_scope.If i try rake task separately means its working. > > > On Wed, Mar 9, 2011 at 5:24 PM, Frederick Cheung < > frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> >> >> On Mar 9, 11:25 am, Colin Law <clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> > I had noticed that some queries don''t get run till the collection is >> > used, whereas others seem to run immediately. I did not find >> > documented exactly how to tell in advance which will get run and which >> > won''t. I wonder whether using a named scope would guarantee delayed >> > operation. >> >> (named) scopes are lazily evaluated. >> >> Fred >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Talk" group. >> To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >> To unsubscribe from this group, send email to >> rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-talk?hl=en. >> >> >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law
2011-Mar-09 12:25 UTC
Re: Re: Fragment caching and not accessing model from view
On 9 March 2011 11:54, Frederick Cheung <frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > On Mar 9, 11:25 am, Colin Law <clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> I had noticed that some queries don''t get run till the collection is >> used, whereas others seem to run immediately. I did not find >> documented exactly how to tell in advance which will get run and which >> won''t. I wonder whether using a named scope would guarantee delayed >> operation. > > (named) scopes are lazily evaluated.OK, I provided a scope scope :all_varieties with no parameters. Then in the controller @varieties = Variety.all_varieties and have confirmed that if the fragment is already cached so @varieties is not used in the view, then the query is not run, so no need test whether the fragment exists when setting up @varieties. This is the best solution I think. Thanks again Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law wrote in post #986452:> On 9 March 2011 11:54, Frederick Cheung <frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > OK, I provided a scope > scope :all_varieties > with no parameters. > > Then in the controller > @varieties = Variety.all_varieties > and have confirmed that if the fragment is already cached so > @varieties is not used in the view, then the query is not run, so no > need test whether the fragment exists when setting up @varieties. > > This is the best solution I think. > > Thanks again > > ColinAck... obfuscated logic. If you are trying to not make the call when the cache fragment already exists, then don''t do so. @varieties = Variety.all unless fragment_exist?( ''select_box'' ) Don''t squirrel it away behind a scope which does nothing except let you defer the decision about executing the DB read and depend on a behavior of AR which is determined when the view is being rendered... Just a personal opinion. What works for you, works for you. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Xavier Noria
2011-Mar-09 22:18 UTC
Re: Re: Re: Fragment caching and not accessing model from view
On Wed, Mar 9, 2011 at 11:08 PM, Ar Chron <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Ack... obfuscated logic. If you are trying to not make the call when > the cache fragment already exists, then don''t do so. > > @varieties = Variety.all unless fragment_exist?( ''select_box'' ) > > Don''t squirrel it away behind a scope which does nothing except let you > defer the decision about executing the DB read and depend on a behavior > of AR which is determined when the view is being rendered...+1 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law
2011-Mar-10 07:24 UTC
Re: Re: Re: Fragment caching and not accessing model from view
On 9 March 2011 22:08, Ar Chron <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Colin Law wrote in post #986452: >> On 9 March 2011 11:54, Frederick Cheung <frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> wrote: >> >> OK, I provided a scope >> scope :all_varieties >> with no parameters. >> >> Then in the controller >> @varieties = Variety.all_varieties >> and have confirmed that if the fragment is already cached so >> @varieties is not used in the view, then the query is not run, so no >> need test whether the fragment exists when setting up @varieties. >> >> This is the best solution I think. >> >> Thanks again >> >> Colin > > Ack... obfuscated logic. If you are trying to not make the call when > the cache fragment already exists, then don''t do so.Sorry I am not sure what you are saying is best, are you suggesting I *should* use fragment_exist? or I should not? Colin> > @varieties = Variety.all unless fragment_exist?( ''select_box'' ) > > Don''t squirrel it away behind a scope which does nothing except let you > defer the decision about executing the DB read and depend on a behavior > of AR which is determined when the view is being rendered...-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Colin Law
2011-Mar-10 07:25 UTC
Re: Re: Fragment caching and not accessing model from view
On 9 March 2011 11:59, anu priya <anuhema1989-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> hi, > I also have a query how to integrate rake task with cronjobs any idea how > to use with example.What has that got to do with the subject of this thread (fragment caching)?> > Anu > > On Wed, Mar 9, 2011 at 5:28 PM, anu priya <anuhema1989-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> hi fred, >> >> Ya i can get your point,but in rails we will use scope instead of >> named_scope.If i try rake task separately means its working. >> >> On Wed, Mar 9, 2011 at 5:24 PM, Frederick Cheung >> <frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>> >>> >>> On Mar 9, 11:25 am, Colin Law <clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >>> > I had noticed that some queries don''t get run till the collection is >>> > used, whereas others seem to run immediately. I did not find >>> > documented exactly how to tell in advance which will get run and which >>> > won''t. I wonder whether using a named scope would guarantee delayed >>> > operation. >>> >>> (named) scopes are lazily evaluated. >>> >>> Fred >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Ruby on Rails: Talk" group. >>> To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >>> To unsubscribe from this group, send email to >>> rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org >>> For more options, visit this group at >>> http://groups.google.com/group/rubyonrails-talk?hl=en. >>> >> > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.