" but any schema change will break it "
How do you mean? You don't have to specify the columns in Cassandra so it
should work perfect. Except for the "skill~" is preserverd for your list.
2012/3/26 samal <samalgo...@gmail.com>
>
> Save the skills in a single column in json format. Job done.
>>
> Good if it have fixed set of skills, then any add or delete changes need
> handle in app. ->read column first->reformat JOSN->update column (2 thrift
> calls).
>
> skill~Java: null,
> skill~Cassandra: null
> This is also good option, but any schema change will break it.
>
>
> On Mar 26, 2012 7:04 PM, "Ben McCann" <b...@benmccann.com> wrote:
>>
>>> True. But I don't need the skills to be searchable, so I'd rather embed
>>> them in the user than add another top-level CF. I was thinking of doing
>>> something along the lines of adding a skills super column to the User table:
>>>
>>> skills: {
>>> 'java': null,
>>> 'c++': null,
>>> 'cobol': null
>>> }
>>>
>>> However, I'm still not sure yet how to accomplish this with Astyanax.
>>> I've only figured out how to make composite columns with predefined column
>>> names with it and not dynamic column names like this.
>>>
>>>
>>>
>>> On Mon, Mar 26, 2012 at 9:08 AM, R. Verlangen <ro...@us2.nl> wrote:
>>>
>>>> In this case you only neem the columns for values. You don't need the
>>>> column-values to hold multiple columns (the super-column principle). So a
>>>> normal CF would work.
>>>>
>>>>
>>>> 2012/3/26 Ben McCann <b...@benmccann.com>
>>>>
>>>>> Thanks for the reply Samal. I did not realize that you could store a
>>>>> column with null value. Do you know if this solution would work with
>>>>> composite columns? It seems super columns are being phased out in favor
>>>>> of
>>>>> composites, but I do not understand composites very well yet. I'm trying
>>>>> to figure out if there's any way to accomplish what you've suggested using
>>>>> Astyanax <https://github.com/Netflix/astyanax>.
>>>>>
>>>>> Thanks for the help,
>>>>> Ben
>>>>>
>>>>>
>>>>> On Mon, Mar 26, 2012 at 8:46 AM, samal <samalgo...@gmail.com> wrote:
>>>>>
>>>>>> plus it is fully compatible with CQL.
>>>>>> SELECT * FROM UserSkill WHERE KEY='ben';
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 26, 2012 at 9:13 PM, samal <samalgo...@gmail.com> wrote:
>>>>>>
>>>>>>> I would take simple approach. create one other CF "UserSkill" with
>>>>>>> row key same as profile_cf key,
>>>>>>> In user_skill cf will add skill as column name and value null.
>>>>>>> Columns can be added or removed.
>>>>>>>
>>>>>>> UserProfile={
>>>>>>> '*ben*'={
>>>>>>> blah :blah
>>>>>>> blah :blah
>>>>>>> blah :blah
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> UserSkill={
>>>>>>> '*ben*'={
>>>>>>> 'java':''
>>>>>>> 'cassandra':''
>>>>>>> .
>>>>>>> .
>>>>>>> .
>>>>>>> 'linux':''
>>>>>>> 'skill':'infinity'
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 26, 2012 at 12:34 PM, Ben McCann <b...@benmccann.com>wrote:
>>>>>>>
>>>>>>>> I have a profile column family and want to store a list of skills
>>>>>>>> in each profile. In BigTable I could store a Protocol
>>>>>>>> Buffer<http://code.google.com/apis/protocolbuffers/docs/overview.html>with
>>>>>>>> a repeated field, but I'm not sure how this is typically accomplished
>>>>>>>> in Cassandra. One option would be to store a serialized
>>>>>>>> Thrift<http://thrift.apache.org/>or protobuf, but I'd prefer not to do
>>>>>>>> this as I believe Cassandra doesn't
>>>>>>>> have knowledge of these formats, and so the data in the datastore
>>>>>>>> would not
>>>>>>>> not human readable in CQL queries from the command line. The other
>>>>>>>> solution I thought of would be to use a super column and put a random
>>>>>>>> UUID
>>>>>>>> as the key for each skill:
>>>>>>>>
>>>>>>>> skills: {
>>>>>>>> '4b27c2b3ac48e8df': 'java',
>>>>>>>> '84bf94ea7bc92018': 'c++',
>>>>>>>> '9103b9a93ce9d18': 'cobol'
>>>>>>>> }
>>>>>>>>
>>>>>>>> Is this a good way of handling lists in Cassandra? I imagine
>>>>>>>> there's some idiom I'm not aware of. I'm using the
>>>>>>>> Astyanax<https://github.com/Netflix/astyanax/wiki>client library,
>>>>>>>> which only supports composite columns instead of super
>>>>>>>> columns, and so the solution I proposed above would seem quite awkward
>>>>>>>> in
>>>>>>>> that case. Though I'm still having some trouble understanding
>>>>>>>> composite
>>>>>>>> columns as they seem not to be completely documented yet. Would this
>>>>>>>> solution work with composite columns?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ben
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> With kind regards,
>>>>
>>>> Robin Verlangen
>>>> www.robinverlangen.nl
>>>>
>>>>
>>>
>
--
With kind regards,
Robin Verlangen
www.robinverlangen.nl
