[Dbix-class] Caching total_entires in the Pager -- how can build a good cache key?

Peter Rabbitson rabbit+dbic at rabbit.us
Fri Aug 9 17:44:43 GMT 2013


On Fri, Aug 09, 2013 at 07:23:17AM -0700, Bill Moseley wrote:
> On Thu, Aug 8, 2013 at 8:41 PM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrote:
> 
> > >   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' => { tot_cnt => $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.

Most of the time it is not exceedingly horrible but...

> Any plans in having the existing pager code work that way? 

...no because sometimes the plan *is* horrible.

> 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.

And that too

> (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.)

Not only dirty but guaranteed to break in the future - {attrs} will 
eventually disappear. If you can have the role preserve the "clean" rs - 
do that, it will save you a lot of headache down the road.

Cheers




More information about the DBIx-Class mailing list