[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