I've used temporary tables for large search results I've needed to get back to quickly and didn't want to rebuild from scratch...
On Sat, Sep 15, 2012 at 7:06 PM, will trillich <will.trill...@serensoft.com>wrote: > Hi Francisco -- > > I'm not talking about paginating a resultset, I'm talking about returning > to a previously-established resultset on some future HTTP request. Here's > the scenario: > > 12:01 Bob submits search form for "Chicago between 1-Apr-2012 and > 30-Apr-2012" > > 12:02 Bob sees first page of results, records 1-100 > > 12:03 Bob clicks to see second page of results, records 101-200 > <= how do we re-establish the recordset here, from the original search > form at 12:01? > > 12:04 Bob clicks thru to see detail on record 135 > > 12:05 Bob clicks breadcrumbs to "return to search" > <= how do we re-establish the recordset here, from the original search > form at 12:01? > > > > On Sat, Sep 15, 2012 at 2:55 PM, Francisco Obispo <fobi...@isc.org> wrote: > >> Some databases provide means to return a specific set of records, and >> even an offset, >> >> In DBIx::Class, when you search, you can actually specify the "page" as >> an option [1], >> >> if you're not querying against a database, you might want to use >> something like Memcached or the like to store your resultset and paginate >> accordingly. >> >> >> >> >> [1] >> http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm#ATTRIBUTES >> >> >> On Sep 15, 2012, at 11:41 AM, will trillich <will.trill...@serensoft.com> >> wrote: >> >> > User enters some search parameters (location, date-range, etc). Gets >> 500 results which we paginate. Once the user pages to the item of interest, >> he/she can then click thru to edit or see more detail. >> > >> > It'd be nice to have 'breadcrumbs' that take the user back to that page >> of that search. >> > >> > What's the recommended way of doing that? >> > >> > A) stash the whole recordset into the session (can you even >> serialize/deserialize a recordset object?) >> > >> > B) stash the search params and page-no and page-size and recreate the >> recordset each time >> > >> > C) ...something else? >> > >> > >> > >> > -- >> > Will Trillich :: 812.454.6431 >> > >> > “Waiting for perfect is never as smart as making progress.” -- Seth >> Godin >> > _______________________________________________ >> > List: Catalyst@lists.scsys.co.uk >> > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> > Searchable archive: >> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> > Dev site: http://dev.catalyst.perl.org/ >> >> Francisco Obispo >> email: fobi...@isc.org >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC >> PGP KeyID = B38DB1BE >> >> >> _______________________________________________ >> List: Catalyst@lists.scsys.co.uk >> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst >> Searchable archive: >> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ >> Dev site: http://dev.catalyst.perl.org/ >> > > > > -- > Will Trillich :: 812.454.6431 > > “Waiting for perfect is never as smart as making progress.” -- Seth Godin > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: > http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ > > -- Steve Rippl Technology Director Woodland Public Schools 360 841 2730
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
