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 >
