Hi, What Stack says is right and the same for trunk, i.e. when you ask with a specific timestamp and have not compacted the stores yet you will see the specific version even if there are 3 or more newer ones. The logic is in the ScanQueryMatcher.match() function. It skips the newer version and does not count them against the versions seen. When it finds the exact match by timestamp it assumes it has only "tracked" 0 versions before seeing this match and returns it.
Lars On Dec 20, 2010, at 17:34, Stack <[email protected]> wrote: > On Mon, Dec 20, 2010 at 2:56 AM, Mohit <[email protected]> wrote: > ... > >> So I updated the value of a column 5 times programmatically , and expected >> result was if I query the value for the oldest entry i.e. by supplying the >> timestamp of the 4th or 5th entry, I should get null or some kind of >> exception, but actually it is persisting oldest values thereby overshooting >> the maxVersions value. >> > > A few things: > > + HBase persists all you add to it. Only when a garbage collection > runs -- a 'major compaction' -- do versions beyond maxversions and/or > TTL settings get cleared out. Meantime, queries should respect your > schema configurations such that if you ask for all versions of a cell, > only those that are less than TTL setting and less than maxversions > will be returned. > + If you ask for an explicit version before the major compactions has > run, in 0.20.6, we'll probably return the explicit version. I haven't > checked how it runs in the next version, 0.90.0. > > St.Ack
