We're going to pass on the patch for now. It's a bit much of a corner case for the general release.
thanks to folks for taking the time to propose the patch and discuss it though - it's certainly going to be kept in mind. -Dormando On Mon, 9 Mar 2009, Colin Pitrat wrote: > So what's the final status on this patch ? > > 2009/2/23 Jean-Charles Redoutey <[email protected]> > > > this looks like a pretty efficient summary of the whole thread ! > > > > To come back on Dormando's point: any global consistency issue can be > > solved by full flush, so I can't honestly say it is an absolutely necessary > > feature. However, by dramatically reducing the DB cost of such flush > > operations, (you can't save resources as this is still needed for > > reliabitily, ok) but you don't have to think twice (or argument 2 hours with > > your DBA) anymore and thus you can do it when you fonctionally want, which > > ultimate result is to give a significant higher quality to the data hosted > > in the cache, and this is probably worth 10 lines of code ;-) > > > > To make a bad comparison, it's like ABS brakes: a very good driver can be > > more efficient, you can still break without it ... but with it, the whole > > road network is safer ! > > > > Back to your post, Dustin, could you detail what you mean by "generational > > prefix mechanism", or give a pointer? I think I almost figure out the idea, > > but not the whole details and google didn't find much about prefix in the > > mailing list for me... > > --- > > Jean-Charles > > > > > > > > On Mon, Feb 23, 2009 at 20:31, Dustin <[email protected]> wrote: > > > >> > >> > >> On Feb 22, 5:02 pm, dormando <[email protected]> wrote: > >> > >> > It feels excessive if the only real benefit is being able to do a full > >> > data flush in less time? Is there anything I'm missing? > >> > >> This is kind of how I see it: > >> > >> Pros: > >> > >> * It's consistent with flush_all [n] for positive values of n if you > >> consider flush_all to mean "remove items older than n" > >> * The patch is really small and simple. > >> * This is functionality that can't be performed (exactly) on the > >> client side (would've been a good argument against flush_all n). > >> > >> Cons: > >> > >> * It's inconsistent with flush_all if you think of flush_all as > >> "remove all objects" > >> * Item structure overhead is increased. > >> * Generally raises the "this will be abused" flag > >> > >> > >> As far as not being possible to do without the server change (pro > >> #3), this can be done with a generational prefix mechanism, which I'd > >> expect to be preferable as it would be more exact than time. > >> > >> > > >
