This was on hector-users this morning as well. It has been addressed and is now in trunk.
-Nate On Thu, May 6, 2010 at 2:35 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > That's kind of an odd API wart for Hector. You should file an issue > on http://github.com/rantav/hector > > On Thu, May 6, 2010 at 11:36 AM, Jonathan Shook <jsh...@gmail.com> wrote: >> I found the issue. Timestamp ordering was broken because: >> I generated a timestamp for the group of operations. Then, I used >> hector's remove, which generates its own internal timestamp. >> I then re-used the timestamp, not wary of the missing timestamp field >> on the remove operation. >> >> The fix was to simply regenerate my timestamp after any hector >> operation which generates its own. >> >> In my case, hector generates it's own internal timestamp for removes, >> but not other operations. Until the timestamp resolution is better >> than milliseconds, it's very possible to end up with the same >> timestamp for tightly grouped operations, which may lead to unexpected >> behavior. I've submitted a request to simplify this. >> >> On Wed, May 5, 2010 at 5:03 PM, Jonathan Shook <jsh...@gmail.com> wrote: >>> When I try to replace a set of columns, like this: >>> >>> 1) remove all columns under a CF/row >>> 2) batch insert columns into the same CF/row >>> .. the columns cease to exist. >>> >>> Is this expected? >>> >>> This is just across 2 nodes with Replication Factor 2 and Consistency >>> Level QUOROM. >>> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of Riptano, the source for professional Cassandra support > http://riptano.com >
