[
https://issues.apache.org/jira/browse/SAMZA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13838063#comment-13838063
]
Alan Li commented on SAMZA-94:
------------------------------
Solution #2 appears like a cleaner solution because I imagine that clients can
easily miss this detail even if it's documented.
Separately, given the behavior that you've described above, the following might
be unexpected for clients:
{noformat}
kv.put('foo', someValue); // stores 'foo' with someValue
kv.all(); // iterator will have key 'foo'
kv.put('foo', null); // actually deletes 'foo'...
kv.all(); // iterator will not have key 'foo'
{noformat}
Given this behavior, would it be better for kv.put() to prevent null values?
> State management kv-store delete() does not remove key
> ------------------------------------------------------
>
> Key: SAMZA-94
> URL: https://issues.apache.org/jira/browse/SAMZA-94
> Project: Samza
> Issue Type: Bug
> Components: kv
> Affects Versions: 0.6.0
> Reporter: Alan Li
> Assignee: Chris Riccomini
> Fix For: 0.7.0
>
>
> Sample code snippet:
> {noformat}
> _realtimeStateStore.put("foo", new HashMap());
>
> KeyValueIterator<String, Map<String, State>> realtimeIterator =
> _realtimeStateStore.all();
> while (realtimeIterator.hasNext())
> {
> Entry<String, Map<String, State>> entry = realtimeIterator.next();
> System.out.println("read from leveldb: " + entry.getKey() + "=>" +
> entry.getValue());
> }
> realtimeIterator.close();
>
> _realtimeStateStore.delete("foo");
>
> KeyValueIterator<String, Map<String, State>> iter =
> _realtimeStateStore.all();
> while (iter.hasNext())
> {
> Entry<String, Map<String, State>> entry = iter.next();
> System.out.println("read from leveldb: " + entry.getKey() + "=>" +
> entry.getValue());
> }
> iter.close();
> {noformat}
> Output:
> read from leveldb: foo=>{}
> read from leveldb: foo=>null
> I would expect that the kv would remove both the key & value on delete so
> that subsequent iterators will not return keys that have been deleted.
--
This message was sent by Atlassian JIRA
(v6.1#6144)