On Mon, Mar 8, 2010 at 9:30 AM, Jonathan Ellis <jbel...@gmail.com> wrote:
> On Mon, Mar 8, 2010 at 11:22 AM, Erik Holstad <erikhols...@gmail.com> > wrote: > > I was probably a little bit unclear here. I'm wondering about the two > byte[] > > in Column. > > One for name and one for value. I was under the impression that the > > skiplistmap > > wraps the Columns, not that the name and the value are themselves > inserted > > into a map? > > The column name is the key in one such map, yes. > So why is it again that the value field in the Column cannot be null if it is not the value field in the map, but just a part of the value field? > > >> > is it really that expensive to check if the list is empty before > >> > returning > >> > that row > >> > >> Yes, because you have to check the entire row, which may be much > >> larger than the given predicate. > > > > That makes sense, but why would you be interested in the rows present > > outside > > your specified predicate? > > Because get_range_slice says, "apply this predicate to the range of > rows given," meaning, if the predicate result is empty, we have to > include an empty result for that row key. It is perfectly valid to > perform such a query returning empty column lists for some or all > keys, even if no deletions have been performed. So to special case > leaving out result entries for deletions, we have to check the entire > rest of the row to make sure there is no undeleted data anywhere else > either (in which case leaving the key out would be an error). > All of this makes total sense, I'm wondering about use cases where you want to get an empty row when you don't know if it has been deleted or not. -- Regards Erik
