Details
-
Bug
-
Status: Resolved
-
Critical
-
Resolution: Duplicate
-
1.6.1
-
None
-
None
Description
Noticed the following when I was poking around with ExamplesIT#testStatsCombiner:
String table = getUniqueNames(1)[0]; c.tableOperations().create(table); is = new IteratorSetting(10, StatsCombiner.class); StatsCombiner.setCombineAllColumns(is, true); c.tableOperations().attachIterator(table, is); bw = c.createBatchWriter(table, bwc); Mutation m = new Mutation("foo"); m.put("a", "b", "1"); m.put("a", "b", "3"); bw.addMutation(m); bw.flush(); Iterator<Entry<Key,Value>> iter = c.createScanner(table, Authorizations.EMPTY).iterator(); assertTrue("Iterator had no results", iter.hasNext()); Entry<Key,Value> e = iter.next(); assertEquals("Results ", "1,3,4,2", e.getValue().toString());
When run against the Java maps, the above succeeds as the test expects it to. However, this fails when the instance is using native maps.
Talked to kturner about this, and he noted that the Java maps use a one-up counter when performing updates whereas it does not appear that the NativeMap does this.
The reason I got stuck on it is because I expected to see both updates because the StatsCombiner was running below the VersioningIterator, but I would only see a single Key-Value out of the scanner (a value of "3,3,3,1").
My gut reaction is that we should have the same semantics across both Java and Native maps, although I'm not sure which one is correct/expected yet.
Attachments
Issue Links
- duplicates
-
ACCUMULO-4148 Native map should increment counter for every cell
- Resolved
- relates to
-
ACCUMULO-1528 Scans should deterministically return entries with identical timestamps
- Open
-
ACCUMULO-1527 the same key should not be returned more than once to clients
- Open
-
ACCUMULO-197 remove the VersioningIterator: inserting duplicate keys gives duplicate keys on scan
- Resolved
-
ACCUMULO-227 Improve in memory map counts to provide cell level uniqueness for repeated columns in mutation
- Resolved