[Dbix-class] Caching total_entires in the Pager -- how can build
a good cache key?
Bill Moseley
moseley at hank.org
Fri Aug 9 14:23:17 GMT 2013
On Thu, Aug 8, 2013 at 8:41 PM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrot=
e:
> > So, I'm thinking about caching.
>
> Don't. It won't change frequrently until it does.
>
True. A row might get added (or removed) that adds one more page that we
don't know to show. Nothing is perfect -- a row might get added to page 1,
for example and when going to page 2 a row from page 1 is then bumped down
to page two and is shown again on page 2.
>
> Instead bring in the total entries as a subselect via
> { '+columns' =3D> { tot_cnt =3D> $orig_unpaged_rs->count_rs->as_query } }
> and use $any_result_obj->get_column('tot_cnt') to populate the pager
> tot count.
>
That's interesting. I'll give that a try and look at the query plan.
Any plans in having the existing pager code work that way? I guess one
problem is currently you can ask for the pager w/o running the original
query so that would be a change in behavior.
(In my case I don't have $orig_unpaged_rs as I'm using a role to apply
paging to all the actions that work on collections -- so I'd still have to
"strip" the $rs->{attrs} as in my original, which is a bit dirty.)
Thanks for that tip.
-- =
Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20130809/8d8=
f9033/attachment.htm
More information about the DBIx-Class
mailing list