Jean-Adrien, I wrote a patch that fixes what you saw, care to give it a look? https://issues.apache.org/jira/browse/HBASE-808
If that works for you, we'll close the issue. J-D On Fri, Aug 8, 2008 at 11:15 PM, stack <[EMAIL PROTECTED]> wrote: > Jean-Adrien wrote: > >> ... >> Despite the VERSIONS parameter of the columns (3) it seems that all >> versions >> are stored. >> >> > Yeah. I just confirmed that VERSIONS is not respected doing basic puts in > shell. I made HBASE-808 to cover its fixing. > > Question: is there some garbage collector process that removes the old >> versions ? if yes, when does it take place ? >> >> >> > Yes. At compaction time, versions beyond MAX_VERSIONS (and older than > configured TTL) are removed. > > ... > >> It seems that the row are not inserted. Querying from shell: >> >> >> # SHELL >> hbase(main):004:0> scan 'proxy-0.2' >> ROW COLUMN+CELL >> 0 row(s) in 0.2030 seconds >> >> >> > Playing in the shell, I did not see this behavior; the new insert showed > up. Maybe its something to do w/ the number of inserts you've done. Let me > try and reproduce on my side (Made issue to cover the work: HBASE-809). > > ... > >> I tried other tests, replacing only one column, using an existing >> timestamp >> to modify one single value, inserting past values, and so on... My >> conclusion is either I don't understand the general behaviour of that, or >> I >> make a bad usage of the API. >> > > Your use of the API looks proper. Looks like hbase bugs around > timestamping. > >> Thanks for your work, and if someone has more information about timestamps >> and designed behaviour, I'm very interested in it. >> >> > > Thank you for taking the time to write up the problem in so much helpful > detail. > > St.Ack >
