I agree, that is the way to go. Then each piece of new functionality will
not have to be implemented twice.
On Sat, Feb 12, 2011 at 9:41 AM, Stu Hood wrote:
> I would like to continue to support super columns, but to slowly convert
> them into "compound column names", since that is really all th
I would like to continue to support super columns, but to slowly convert
them into "compound column names", since that is really all they really are.
On Thu, Feb 10, 2011 at 10:16 AM, Frank LoVecchio wrote:
> I've found super column families quite useful when using
> RandomOrderedPartioner on a l
I've found super column families quite useful when using
RandomOrderedPartioner on a low-maintenance cluster (as opposed to
Byte/Ordered), e.g. returning ordered data from a TimeUUID comparator type;
try doing that with one regular column family and secondary indexes (you
could obviously sort on th
Mike, my problem is that I have an database and codebase that already uses
supercolumns. If I had to do it over, it wouldn't use them, for the reasons
you point out. In fact, I have a feeling that over time supercolumns will
become deprecated de facto, if not de jure. That's why I would like to see
: Wednesday, February 09, 2011 20:59
To: user@cassandra.apache.org
Subject: Re: Do supercolumns have a purpose?
I still think super-columns are useful you just need to be aware of
the limitations...
Bye,
Norman
2011/2/9 Mike Malone :
> On Tue, Feb 8, 2011 at 2:03 AM, David Boxenhorn wr
On Thu, 2011-02-03 at 15:35 -0800, Mike Malone wrote:
> In my dealings with the Cassandra code, super columns end up making a
> mess all over the place when algorithms need to be special cased and
> branch based on the column/supercolumn distinction.
>
>
> I won't even mention what it does to t
I still think super-columns are useful you just need to be aware of
the limitations...
Bye,
Norman
2011/2/9 Mike Malone :
> On Tue, Feb 8, 2011 at 2:03 AM, David Boxenhorn wrote:
>>
>> Shaun, I agree with you, but marking them as deprecated is not good enough
>> for me. I can't easily stop usin
On Tue, Feb 8, 2011 at 2:03 AM, David Boxenhorn wrote:
> Shaun, I agree with you, but marking them as deprecated is not good enough
> for me. I can't easily stop using supercolumns. I need an upgrade path.
>
David,
Cassandra is open source and community developed. The right thing to do is
what'
Shaun, I agree with you, but marking them as deprecated is not good enough
for me. I can't easily stop using supercolumns. I need an upgrade path.
On Tue, Feb 8, 2011 at 3:53 AM, Shaun Cutts wrote:
>
> I'm a newbie here, but, with apologies for my presumptuousness, I think you
> should deprecate
I'm a newbie here, but, with apologies for my presumptuousness, I think you
should deprecate SuperColumns. They are already distracting you, and as the
years go by the cost of supporting them as you add more and more functionality
is only likely to get worse. It would be better to concentrate o
"My main point was to say that it's think it is better to create tickets for
what you want, rather than for something else completely different that
would, as a by-product, give you what you want."
Then let me say what I want: I want supercolumn families to have any feature
that regular column fam
On Fri, Feb 4, 2011 at 12:35 AM, Mike Malone wrote:
> On Thu, Feb 3, 2011 at 6:44 AM, Sylvain Lebresne wrote:
>
>> On Thu, Feb 3, 2011 at 3:00 PM, David Boxenhorn wrote:
>>
>>> The advantage would be to enable secondary indexes on supercolumn
>>> families.
>>>
>>
>> Then I suggest opening a ticke
On Thu, Feb 3, 2011 at 3:35 PM, Mike Malone wrote:
> It seems to me that super columns are a historical artifact from Cassandra's
> early life as Facebook's inbox storage system. They needed posting lists of
> messages, sharded by user. So that's what they built. In my dealings with
> the Cassandr
On Thu, Feb 3, 2011 at 6:44 AM, Sylvain Lebresne wrote:
> On Thu, Feb 3, 2011 at 3:00 PM, David Boxenhorn wrote:
>
>> The advantage would be to enable secondary indexes on supercolumn
>> families.
>>
>
> Then I suggest opening a ticket for adding secondary indexes to supercolumn
> families and vo
On Thu, Feb 3, 2011 at 6:49 AM, Jonathan Ellis wrote:
> On Thu, Feb 3, 2011 at 6:44 AM, Sylvain Lebresne wrote:
>> On Thu, Feb 3, 2011 at 3:00 PM, David Boxenhorn wrote:
>>>
>>> The advantage would be to enable secondary indexes on supercolumn
>>> families.
>>
>> Then I suggest opening a ticket
Well, I am an "actual active developer" and I have "managed to do pretty
nice stuffs with Cassandra" - without secondary indexes so far. But I'm
looking forward to having secondary indexes in my arsenal when new
functional requirements come up, and I'm bummed out that my early design
decision to us
On Thu, Feb 3, 2011 at 6:44 AM, Sylvain Lebresne wrote:
> On Thu, Feb 3, 2011 at 3:00 PM, David Boxenhorn wrote:
>>
>> The advantage would be to enable secondary indexes on supercolumn
>> families.
>
> Then I suggest opening a ticket for adding secondary indexes to supercolumn
> families and voti
On Thu, Feb 3, 2011 at 3:00 PM, David Boxenhorn wrote:
> The advantage would be to enable secondary indexes on supercolumn families.
>
Then I suggest opening a ticket for adding secondary indexes to supercolumn
families and voting on it. This will be 1 or 2 order of magnitude less work
than gett
The advantage would be to enable secondary indexes on supercolumn families.
I understand from this thread that indexes are supercolumn families are not
going to be:
http://www.mail-archive.com/user@cassandra.apache.org/msg09527.html
Which, it seems to me, effectively deprecates supercolumn famil
On Thu, Feb 3, 2011 at 1:33 PM, David Boxenhorn wrote:
> Thanks Sylvain!
>
> Can I vote for internally implementing supercolumn families as regular
> column families? (With a smooth upgrade process that doesn't require
> shutting down a live cluster.)
>
I forgot to add that I don't know if this
Thanks Sylvain!
Can I vote for internally implementing supercolumn families as regular
column families? (With a smooth upgrade process that doesn't require
shutting down a live cluster.)
What if supercolumn families were supported as regular column families + an
index (on what used to be supercol
> Is there any advantage to using supercolumns
> (columnFamilyName[superColumnName[columnName[val]]]) instead of regular
> columns with concatenated keys
> (columnFamilyName[superColumnName@columnName[val]])?
>
> When I designed my data model, I used supercolumns wherever I needed two
> levels of k
22 matches
Mail list logo
