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