The referenced article is accurate as far as NULL is concerned, but please also note that there is now the ability to specify UNSET to avoid unnecessary tombstones (as of Cassandra 2.2.0): https://issues.apache.org/jira/browse/CASSANDRA-7304
Adam On Tue, Mar 8, 2016 at 12:15 PM, Henry M <henrymanm...@gmail.com> wrote: > Thank you. It's probably not specific to prepared statements then and just > a more general statement. That makes sense. > > > On Tue, Mar 8, 2016 at 10:06 AM Steve Robenalt <sroben...@highwire.org> > wrote: > >> Hi Henry, >> >> I would suspect that the tombstones are necessary to overwrite any >> previous values in the null'd columns. Since Cassandra avoids >> read-before-write, there's no way to be sure that the nulls were not >> intended to remove any such previous values, so the tombstones insure that >> they don't re-appear. >> >> Steve >> >> >> >> On Tue, Mar 8, 2016 at 9:36 AM, Henry Manasseh <henrymanm...@gmail.com> >> wrote: >> >>> The following article makes the following statement which I am trying to >>> understand: >>> >>> *"Cassandra’s storage engine is optimized to avoid storing unnecessary >>> empty columns, but when using prepared statements those parameters that are >>> not provided result in null values being passed to Cassandra (and thus >>> tombstones being stored)." * >>> http://www.datastax.com/dev/blog/4-simple-rules-when-using-the-datastax-drivers-for-cassandra >>> >>> I was wondering if someone could help explain why sending nulls as part >>> of a prepared statement update would result in tombstones. >>> >>> Thank you, >>> - Henry >>> >> >> >> >> -- >> Steve Robenalt >> Software Architect >> sroben...@highwire.org <bza...@highwire.org> >> (office/cell): 916-505-1785 >> >> HighWire Press, Inc. >> 425 Broadway St, Redwood City, CA 94063 >> www.highwire.org >> >> Technology for Scholarly Communication >> >
