For Accumulo, what you're referring to as a "null" is really the absence of a cell. To update a column to "null" when it previously had a value, in Accumulo is the same as deleting it. So, you would use `mutation.putDelete()` in the API to insert a "null" placeholder to delete a version, or "delete" in the shell.
However, the semantics of Accumulo's deletes are a bit particular. To Accumulo, a delete marker doesn't just represent that the current value is null, it is also an indicator to remove all prior versions of that cell. This may not be what you want. If not, then you will have to adopt a different strategy of storing "nulls". Perhaps by storing an empty byte array, or some special marker known to your application to represent "null" as a value. If you adopt this strategy, you probably wouldn't use regular delete markers, and so may wish to try out the experimental feature to change the way deletes are handled: https://accumulo.apache.org/docs/2.x/configuration/server-properties#table_delete_behavior On Fri, Dec 4, 2020 at 5:24 PM Brad Barber <[email protected]> wrote: > Hi all! > > I'm new to Accumulo and trying to implement table versioning with it. > Since Accumulo doesn't store nulls, what I'm seeing is that, using the > VersioningIterator, when I try to update a row in a table where some of the > column values are null I get a partial row update. That is, for the columns > which were null in the update, the previous version's value is retained and > returned. I understand why this is happening since Accumulo won't store KV > pairs. This is great for partial row updates, but what is the commonly > accepted method (if there is one) for updating cells to null? I realise I > could just set the timestamp range to only include the updated KV pairs, > this would then return null for the columns which were null in the update, > but this doesn't help when I want to get the current version of the table > which includes historical data and updates. Any help would be greatly > appreciated 🙂 I'm really enjoying learning Accumulo but this problem has > me stumped... >
