I was given one other suggestion (which may have been suggested earlier in this thread, but is clearer to me with an example). The suggestion was to use composite columns and have the first part of the key name be "skill" and the second part be the specific skill and then store a null value. I hope I understood this suggestion correctly.
YEAH! agree, it only matter for time bucket data.On Tue, Mar 27, 2012 at 12:31 PM, R. Verlangen <email@example.com> wrote:
That's true, but it does not sound like a real problem to me.. Maybe someone else can shed some light upon this.2012/3/27 samal <firstname.lastname@example.org>
On Tue, Mar 27, 2012 at 1:47 AM, R. Verlangen <email@example.com> wrote:
" 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.
In case skill~ is decided to change to skill:: , it need to be handle at app level. Or otherwise had t update in all row, read it first, modify it, insert new version and delete old version.
With kind regards,Robin Verlangen