Hello. I have a question on the best way to handle result sets in between user interactions, such as pagination. To elaborate, if a user performs a search for some items, and you only display the first 10 results of say 10000, how do you handle the other 9990 results in between requests? Here are a couple of choices: 1) Don''t save them. Just discard them and re-run the query during each new request and only return the results for the corresponding page. This could in theory be optimized to only return the results that you would display. I say "in theory" because if you are retrieving from a data source that does not allow you to narrow the results with ranges then you would just have to bite the bullet and grab them all over again. 2) Store the results in the session. 3) Store the results somewhere else. 4) Something else? Perhaps a combination of storing some manageable number of results in the session and then rerunning the query if needed. Perhaps there is not a one size fits all approach to this, but I would like to hear some other people''s experience and perspective on this. Thanks, Tom
Just off the top of my head... Personally, I get annoyed when I get a paginated result, pause on that page for a bit, then get some overlap in results when I move to the next page. In this case, obviously the query is being re-run (or it generated duplicate results in the first place). Depending on the overhead, I might store the ones that have already been viewed, and if that set intersects with the results returned by the next query, I''d remove the overlapping ones. Of course, this may be a little problematic if the user can skip around to a particular page number. In that case, I''d probably just store the returned results (or at least an index for each row), and not re-run the query. On Oct 20, 2005, at 7:55 AM, Tom Davies wrote:> Hello. > > I have a question on the best way to handle result sets in between > user interactions, such as pagination. To elaborate, if a user > performs a search for some items, and you only display the first 10 > results of say 10000, how do you handle the other 9990 results in > between requests? > > Here are a couple of choices: > > 1) Don''t save them. Just discard them and re-run the query during > each new request and only return the results for the corresponding > page. This could in theory be optimized to only return the results > that you would display. I say "in theory" because if you are > retrieving from a data source that does not allow you to narrow the > results with ranges then you would just have to bite the bullet and > grab them all over again. > > 2) Store the results in the session. > > 3) Store the results somewhere else. > > 4) Something else? Perhaps a combination of storing some manageable > number of results in the session and then rerunning the query if > needed. > > Perhaps there is not a one size fits all approach to this, but I would > like to hear some other people''s experience and perspective on this. > > Thanks, > Tom > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Thursday 20 October 2005 13:55, Tom Davies wrote:> I have a question on the best way to handle result sets in between > user interactions, such as pagination. To elaborate, if a user > performs a search for some items, and you only display the first 10 > results of say 10000, how do you handle the other 9990 results in > between requests?I don''t think there is one best way. It very much depends on how your app is used. My setting is like this * It''s an in-house app with only few concurrent users. * Load on the server is essentially zero. * Database access time is negligible (particularly compared to the time Rails spends on "objectifying" and rendering -- sigh). * Results for list views can encompass as many as 10.000 items. Obviously, I can''t display up to 10.000 rows on a single page. Therefore I''m grudgingly using pagination as I unable to fit Rico''s LiveGrid into my app. When a user selects an item in the list view for editing, they get an edit view with buttons for first/previous/next/last to navigate in the *entire* result list. Also, edit view may contain lists of associated objects. Users can drill down to edit views for these objects, too. Again, there are navigation buttons, this time for moving among all the objects associated to the superordinate object. The implementation can be decomposed into several pieces. Pagination: First I get the count of all matching objects. Then I get only the matching objects I can display on a single page from the database, using offset and limit. Navigation: I also get the ids of *all* the objects matching a query and store them on a navigation stack kept in the session. In my setting, I have no qualms blowing up the session, but I''d advice against doing it on a busy public site. The put down is that you can hardly do this with vanilla Rails as of 0.13.1 or 0.14. AR doesn''t support :conditions referring to included associations. You can''t count the size of the result set in that case, either. Retrieving only the ids of a large number of objects is not possible when :conditions are involved and getting proper AR instances and retaining only their ids is way too slow. Michael -- Michael Schuerig Most people would rather die than think. mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org In fact, they do. http://www.schuerig.de/michael/ --Bertrand Russell
Thanks for the responses. I had a feeling there really wasn''t a perfect solution, so I guess it really is just find the best fit for the situation. Thanks again. Tom On 10/20/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> On Thursday 20 October 2005 13:55, Tom Davies wrote: > > > I have a question on the best way to handle result sets in between > > user interactions, such as pagination. To elaborate, if a user > > performs a search for some items, and you only display the first 10 > > results of say 10000, how do you handle the other 9990 results in > > between requests? > > I don''t think there is one best way. It very much depends on how your > app is used. My setting is like this > > * It''s an in-house app with only few concurrent users. > * Load on the server is essentially zero. > * Database access time is negligible (particularly compared to the time > Rails spends on "objectifying" and rendering -- sigh). > * Results for list views can encompass as many as 10.000 items. > > Obviously, I can''t display up to 10.000 rows on a single page. Therefore > I''m grudgingly using pagination as I unable to fit Rico''s LiveGrid into > my app. When a user selects an item in the list view for editing, they > get an edit view with buttons for first/previous/next/last to navigate > in the *entire* result list. Also, edit view may contain lists of > associated objects. Users can drill down to edit views for these > objects, too. Again, there are navigation buttons, this time for moving > among all the objects associated to the superordinate object. > > The implementation can be decomposed into several pieces. Pagination: > First I get the count of all matching objects. Then I get only the > matching objects I can display on a single page from the database, > using offset and limit. > > Navigation: I also get the ids of *all* the objects matching a query and > store them on a navigation stack kept in the session. In my setting, I > have no qualms blowing up the session, but I''d advice against doing it > on a busy public site. > > The put down is that you can hardly do this with vanilla Rails as of > 0.13.1 or 0.14. AR doesn''t support :conditions referring to included > associations. You can''t count the size of the result set in that case, > either. Retrieving only the ids of a large number of objects is not > possible when :conditions are involved and getting proper AR instances > and retaining only their ids is way too slow. > > Michael > > -- > Michael Schuerig Most people would rather die than think. > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org In fact, they do. > http://www.schuerig.de/michael/ --Bertrand Russell > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Is there any way to shutdown webrick other than using the kill command? Is there a standard way to install rails so it automatically starts? (I''m not really a *nix guy... this is all running on linux) We want to write an automated deployment script that shuts down the server, ftps the rails code out, and restarts. Thanks!
On Oct 20, 2005, at 2:58 PM, Phil Swenson wrote:> Is there any way to shutdown webrick other than using the kill > command? Is > there a standard way to install rails so it automatically starts? > (I''m not > really a *nix guy... this is all running on linux)The TERM signal is the standard way to shutdown Rails'' webrick server. As for automatically starting rails, I assume you mean you want webrick to start automatically? Seems like each flavor of linux has its own way of doing things, so it probably depends on what linux you''re using.> We want to write an automated deployment script that shuts down the > server, > ftps the rails code out, and restarts.You may want to check out SwitchTower (http://manuals.rubyonrails.com/ read/book/17). It was created for exactly this purpose. - Jamis
>The TERM signal is the standard way to shutdown Rails'' webrick >server.So are you saying I have to write a script that greps for the process, parse out the process ID and kill it?
You could probably write a script that forks off a webrick process and saves the pid of that child process to a location of your choice. On 10/20/05, Phil Swenson <phil-XITSOACK58NFw/DY4jzso32qnSAIaJbt@public.gmane.org> wrote:> > >The TERM signal is the standard way to shutdown Rails'' webrick > >server. > > So are you saying I have to write a script that greps for the process, parse > out the process ID and kill it? > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Ryan Raaum http://www.rockefeller.edu -- Bacterial Pathogenesis and Immunology http://www.worldmartial.com -- Black Belt Instructor http://locomotive.sourceforge.net -- Self contained one-click Rails for Mac OS X
Ryan Raaum wrote:> You could probably write a script that forks off a webrick process and > saves the pid of that child process to a location of your choice.(normally that location is /var/run/nameofprocess.pid ) This is certainly the way well behaved initscripts do it. The bad quick n dirty way to do it is hoping you have the killall command but this later method will inevitably come back to haunt you...