Row column_[names,values] will only return columns. #5

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

psanford commented Aug 19, 2011

These methods now exclude the row_key from their results.

Row column_[names,values] will only return columns.
These methods now exclude the row_key from their results.
Owner

kreynolds commented Aug 19, 2011

I actually had written it this way originally and different people interpret it differently. I had a long chat with Jonathan Ellis in #cassandra-dev about the fuzzy nature of seeing the row key as a column sometimes and not other times and we landed on the following scenarios:

  1. Wildcard query should return the row_key as it's key_alias as if it is a column. I filed ticket #3036 to address potential confusion when creating column meta_data and it's been resolved already and should be in the next release.
  2. A column slice should not include the row_key if the key_alias would appear in the slice
  3. Selecting via explicit column_name, key_alias returns exactly what you'd expect.

The current behavior is correct in all 3 of these scenarios. There is a bug where if you 'select id, col1..col3', it will throw an error instead of returning that but that's a CQL bug that may or may not get fixed depending on what happens with the CompositeType implementation. Have to pass on this one .. sorry.

@kreynolds kreynolds closed this Aug 19, 2011

Contributor

psanford commented Aug 19, 2011

It seems like this logic is really intended to fix the miss match between cassandra and standard database interfaces (e.g. JDBC) that can't explicitly expose the row key. I can see why you would want to keep this consistent with other language CQL driver implementations.

Would you consider adding methods to the API that would return only the columns?

Owner

kreynolds commented Aug 19, 2011

Everything will return only columns unless you use a wildcard. If you use a wildcard, the first column is always the key so you can start at 1. There isn't really a graceful way to deal with this other than to just know about it. If in the future it becomes a real burden for most use cases we'll revisit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment