[Catalyst] Best-practices question: caching a search

[Rippl, Steve]

To be honest this was on a low use internal app, and a new search would
trigger cycling the temp table.  I just threw this out there, but sure, you
could key it by session or perhaps have multiple temp tables depending on
traffic, and I'm sure you'd have to clean them up after some period,
again depending on traffic and capacity.

I don't know if this is best practice, I just found it useful for
navigating back and forth to a large search resultset...



On Sat, Sep 15, 2012 at 7:23 PM, will trillich
<will.trillich at serensoft.com>wrote:

> Steve --
>
> Does that work when someone starts a search and then goes to lunch and
> comes back the next day to click "next"? Do you key it to the session ID
> somehow?
>
>
>
> On Sat, Sep 15, 2012 at 9:21 PM, Rippl, Steve <rippls at woodlandschools.org=
>wrote:
>
>> 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.trillich at 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
>>>   <=3D how do we re-establish the recordset here, from the original sea=
rch
>>> form at 12:01?
>>>
>>> 12:04 Bob clicks thru to see detail on record 135
>>>
>>> 12:05 Bob clicks breadcrumbs to "return to search"
>>>   <=3D how do we re-establish the recordset here, from the original sea=
rch
>>> form at 12:01?
>>>
>>>
>>>
>>> On Sat, Sep 15, 2012 at 2:55 PM, Francisco Obispo <fobispo at isc.org>wrot=
e:
>>>
>>>> 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 pagin=
ate
>>>> accordingly.
>>>>
>>>>
>>>>
>>>>
>>>> [1]
>>>> http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm#ATT=
RIBUTES
>>>>
>>>>
>>>> On Sep 15, 2012, at 11:41 AM, will trillich <
>>>> will.trillich at 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 inte=
rest,
>>>> 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
>>>> >
>>>> > =93Waiting for perfect is never as smart as making progress.=94  -- =
Seth
>>>> Godin
>>>> > _______________________________________________
>>>> > List: Catalyst at 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: fobispo at isc.org
>>>> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
>>>> PGP KeyID =3D B38DB1BE
>>>>
>>>>
>>>> _______________________________________________
>>>> List: Catalyst at 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
>>>
>>> =93Waiting for perfect is never as smart as making progress.=94  -- Seth
>>> Godin
>>>
>>> _______________________________________________
>>> List: Catalyst at 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 at 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
>
> =93Waiting for perfect is never as smart as making progress.=94  -- Seth =
Godin
>
> _______________________________________________
> List: Catalyst at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120915/a96d1=
64f/attachment.htm