On 28 July 2011 16:23, Sylvain Lebresne wrote:
> To be honest, collecting the names that were missing in the first name
> query and doing a new name query for those (if there is any) is so simple
> that I think it is a bit dishonest to say that "it pushes work to the
> clients".
>
>
It seems simp
To be honest, collecting the names that were missing in the first name
query and doing a new name query for those (if there is any) is so simple
that I think it is a bit dishonest to say that "it pushes work to the clients".
It seems simple enough at least that it does not sound like a good idea t
I understand and agree for the case where the slice predicate is a range,
but I'd expect the semantics to be different where the predicate is a list
of column names (even if it's implemented using a range operation under the
hood?)
If I ask for columns "foo" and "bar", then usually I'm not trying
No, the slice semantics are "give me whatever happens to exist between
start and end." It's valid for the answer to be "nothing."
On Thu, Jul 28, 2011 at 6:55 AM, David Allsopp wrote:
> If I try to retrieve a column that is not present, using get(), then I'll
> get a NotFoundException.
>
> If (f
If I try to retrieve a column that is not present, using get(), then I'll
get a NotFoundException.
If (for efficiency's sake) I try to retrieve several named columns using
get_slice, with a column_names predicate (i.e. a list of columns) then I
won't get the exception if one of those columns is mi
