Nope. No secondary index. Just a slice query on the PK.
On Tuesday, October 7, 2014, Robert Coli <rc...@eventbrite.com> wrote: > On Tue, Oct 7, 2014 at 3:11 PM, Owen Kim <ohech...@gmail.com > <javascript:_e(%7B%7D,'cvml','ohech...@gmail.com');>> wrote: > >> Sigh, it is a bit grating. I (genuinely) appreciate your acknowledgement >> of that. Though, I didn't intend for the question to be "about" >> supercolumns. >> > > (Yep, understand tho that if you hadn't been told that advice before, it > would grate a lot less. I will try to remember that "Owen Kim" has received > this piece of info, and will do my best to not repeat it to you... :D) > > >> It is possible I'm hitting an odd edge case though I'm having trouble >> reproducing the issue in a controlled environment since there seems to be a >> timing element to it, or at least it's not consistently happening. I >> haven't been able to reproduce it on a single node test cluster. I'm moving >> on to test a larger one now. >> > > Right, my hypothesis is that there is something within the supercolumn > write path which differs from the non-supercolumn write path. In theory > this should be less possible since the 1.2 era supercolumn rewrite. > > To be clear, are you reading back via PK? No secondary indexes involved, > right? The only bells your symptoms are ringing are secondary index bugs... > > =Rob > >
