cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Holstad <erikhols...@gmail.com>
Subject Re: Reason for not allowing null values for in Column
Date Mon, 08 Mar 2010 18:07:54 GMT
On Mon, Mar 8, 2010 at 9:30 AM, Jonathan Ellis <jbellis@gmail.com> wrote:

> On Mon, Mar 8, 2010 at 11:22 AM, Erik Holstad <erikholstad@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

Mime
View raw message