[Catalyst] Best-practices question: caching a search

will trillich will.trillich at serensoft.com
Sun Sep 16 15:55:39 GMT 2012


Roger that -- so: include the search params in the links, and recreate the
recordset each time via ...->search({},{}). Sounds reasonable.

Off to the salt mines...



On Sun, Sep 16, 2012 at 10:07 AM, Bill Moseley <moseley at hank.org> wrote:

>
>
> 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:
>>
>
> You are asking just how to display multiple pages of search results?
>
>
>>
>> 12:01 Bob submits search form for "Chicago between 1-Apr-2012 and
>> 30-Apr-2012"
>>
>
> Use a GET, not a POST.
>
> I'm Ignoring timezones, but you should not.
>
>
> http://example.com/event_list?city=3DChicago&after=3D2012-04-01&before=3D=
2012-04-30&rows=3D100&page=3D1<http://example.com/event_list?city=3DChicago=
&between=3D2012-04-01:2012-04-30&rows=3D100&page=3D1>
>
>
>>
>> 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 sear=
ch
>> form at 12:01?
>>
>
>
> http://example.com/event_list?city=3DChicago&after=3D2012-04-01&before=3D=
2012-04-30&rows=3D100&page=3D<http://example.com/event_list?city=3DChicago&=
between=3D2012-04-01:2012-04-30&rows=3D100&page=3D1>
> 2
>
>
>>
>> 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 sear=
ch
>> form at 12:01?
>>
>
>
> http://example.com/event_list?city=3DChicago&after=3D2012-04-01&before=3D=
2012-04-30&rows=3D100&page=3D1<http://example.com/event_list?city=3DChicago=
&between=3D2012-04-01:2012-04-30&rows=3D100&page=3D1>
>
>
> All independent requests -- someone may bookmark page 2 and go back there
> directly.
>
>
> Then (later) think about caching.   That depends on usage, your database
> load, your SLA, your traffic, load, etc.  You could fetch the entire resu=
lt
> list on the first request and cache, for example, or  you could instead
> cache the entire page (with a separate page cache layer).
>
> Use a cache, not the session, for caching.   There's nothing here related
> to the session unless you wan to display something like "recent searches"
> to show on all pages -- and even that might be better in the cache keyed =
by
> user's ID if users are required to log in.
>
>
>
>>
>>
>>
>> On Sat, Sep 15, 2012 at 2:55 PM, Francisco Obispo <fobispo at 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 pagina=
te
>>> accordingly.
>>>
>>>
>>>
>>>
>>> [1]
>>> http://search.cpan.org/dist/DBIx-Class/lib/DBIx/Class/ResultSet.pm#ATTR=
IBUTES
>>>
>>>
>>> On Sep 15, 2012, at 11:41 AM, will trillich <will.trillich at serensoft.co=
m>
>>> wrote:
>>>
>>> > User enters some search parameters (location, date-range, etc). Gets
>>> 500 results which we paginate. Once the user pages to the item of inter=
est,
>>> 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  -- S=
eth
>>> 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/
>>
>>
>
>
> --
> Bill Moseley
> moseley at hank.org
>
> _______________________________________________
> 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 Go=
din
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20120916/6e33b=
2f6/attachment.htm


More information about the Catalyst mailing list