any better chance for the 1.3 if I make it as a possible 0 extra cost feature like the CAS? ;-)
Jean-Charles On Mar 20, 8:20 am, dormando <[email protected]> wrote: > 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.
