Ok. Great. It works for String and Decimal/Float but not for integer data
type..
i.e,, if I am passing "" to the composite key column which is either text
or float, it works..
session.execute(boundStatement.bind(rowkey, "", ByteBuffer.wrap(value)));
But not working with bigint, int or varint..and getting following exception;
Exception:Invalid type for value 1 of CQL type varint, expecting class
java.math.BigInteger but class java.lang.String provided
..I am exploring more though..
Thanks a ton,
Vikas Goyal
On Tue, Sep 24, 2013 at 9:05 PM, Sylvain Lebresne <sylv...@datastax.com>wrote:
>
> However,we tried missing the value but it didn't work :(
>>
>
> Right, because not providing a value is akin to having a null value (in
> the CQL3 sense of the term, which is different from what Dean asked about)
> and null values are not allowed for primary key columns.
> You could however insert an *empty* value if you wanted, which in you case
> is just inserting an empty string since colname is a string. Thrift doesn't
> allow more or less in that case.
>
> --
> Sylvain
>
>
>
>>
>> So our code is like below where we are using 3 values if colname is not
>> null..else 2 values..
>>
>> if (key != null) {
>> PreparedStatement statement = session.prepare("INSERT
>> INTO keys.StringIndice (id, colname, colvalue) VALUES (?, ?, ?)");
>> BoundStatement boundStatement = new
>> BoundStatement(statement);
>>
>> session.execute(boundStatement.bind(StandardConverters.convertFromBytes(String.class,
>> rowKey), key, ByteBuffer.wrap(value)));
>> } else {
>> PreparedStatement statement = session.prepare("INSERT
>> INTO " + keys + "." + table + "(id, colvalue) VALUES (?, ?)");
>> BoundStatement boundStatement = new
>> BoundStatement(statement);
>>
>> session.execute(boundStatement.bind(StandardConverters.convertFromBytes(String.class,
>> rowKey), ByteBuffer.wrap(value)));
>> }
>>
>> And, I did that and getting this exception:
>>
>> Exception:Missing PRIMARY KEY part colname since colvalue is set
>>
>> And just FYI. Our Column Family definition is below:
>>
>> CREATE TABLE keys.StringIndice (id text,
>> colname text,
>> colvalue blob,
>> PRIMARY KEY (id,colname, colvalue)) WITH COMPACT STORAGE)
>>
>> Thanks again,
>> Vikas Goyal
>>
>>
>>
>> On Tue, Sep 24, 2013 at 7:02 PM, Sylvain Lebresne
>> <sylv...@datastax.com>wrote:
>>
>>> Short answer: not, this is not correct.
>>>
>>> Longer answer: what you call "null" is actually an empty value (which is
>>> *not* the same thing, unless you consider an empty string is the same thing
>>> than a null string). As it happens, C* always an empty value as a valid
>>> value for any type and that's true of both thrift and CQL3. What is true is
>>> that CQL3 discourage the use of empty values for type for which it doesn't
>>> particularly make sense (integers typically) by not having a particular
>>> easy to use syntax to input them. But that's supported nonetheless. If you
>>> use a prepared statement for instance (where you send values already
>>> serialized), nothing will prevent you from sending an empty value. Even if
>>> you don't want to use a prepared statement, CQL3 has conversion functions (
>>> http://cassandra.apache.org/doc/cql3/CQL.html#blobFun) that allows to
>>> do it (for instance, "blobAsInt(0x)" will be an empty int value).
>>>
>>> --
>>> Sylvain
>>>
>>>
>>>
>>> On Tue, Sep 24, 2013 at 2:36 PM, Hiller, Dean <dean.hil...@nrel.gov>wrote:
>>>
>>>> Many applications in thrift use the wide row with composite column name
>>>> and as an example, let's say golf score for instance and we end up with
>>>> golf score : pk like so
>>>>
>>>> null : pk56
>>>> null : pk45
>>>> 89 : pk90
>>>> 89: pk87
>>>> 90: pk101
>>>> 95: pk17
>>>>
>>>> Notice that there are some who do not have a golf score(zero would not
>>>> quite make sense and would be interpreted as a golf score). I am hearing
>>>> from this post if they are correct that this is not portable to CQL3??? Is
>>>> this true?
>>>> http://stackoverflow.com/questions/18963248/how-can-i-have-null-column-value-for-a-composite-key-column-in-cql3
>>>>
>>>> (This sounds like a major deficit to me as the wide row now can only be
>>>> used where actual values exist?????). Is it possible to port this pattern
>>>> to CQL3?
>>>>
>>>> Thanks,
>>>> Dean
>>>>
>>>>
>>>>
>>>
>>
>
