e elegant
solution but it seems unlikely based on the given constraints.
On Fri, Mar 12, 2010 at 5:26 PM, Brandon Williams wrote:
> On Fri, Mar 12, 2010 at 7:21 PM, Peter Chang wrote:
>
>> My original post is probably confusing. I was originally talking about
>> columns
0001']
But Alyssa gets married and changes her name to Zamboni. The next time I
read these subcolumns the user's will not be sorted.
On Fri, Mar 12, 2010 at 5:21 PM, Peter Chang wrote:
> My original post is probably confusing. I was originally talking about
> columns and I don&#
for the sort to be correct.
On Fri, Mar 12, 2010 at 5:10 PM, Brandon Williams wrote:
> On Fri, Mar 12, 2010 at 7:07 PM, Peter Chang wrote:
>
>> But wouldn't name + UUID be considered volatile? That was the crux of my
>> questions.
>
>
> It would, but the distinction here is that it is now a column, not a row
> key.
>
> -Brandon
>
But wouldn't name + UUID be considered volatile? That was the crux of my
questions.
On Fri, Mar 12, 2010 at 1:07 PM, Brandon Williams wrote:
> On Thu, Mar 11, 2010 at 12:54 AM, Peter Chang wrote:
>
>> I'm wondering about good strategies for picking keys that I want to be
I've been thinking more about a similar sort of problem.
The major difference between normal relational databases and big hashtables
is that in the former you can sort and retrieve on any column. In big
hashtables (or at least from Cassandra), you only have 1 field to sort on
and the sort type is
I'm wondering about good strategies for picking keys that I want to be
lexically sorted in a super column family. For example, my data looks like
this:
[user1_uuid][connections][some_key_for_user2] = ""
[user1_uuid][connections][some_key_for_user3] = ""
I was thinking that I wanted some_key_for_u
Sweet I'm in!
Is there going to be a more formal invite? If not, can we get the details on
where Digg is and where at Digg?
Peter
On Tue, Mar 9, 2010 at 9:28 PM, Dan Di Spaltro wrote:
> Great, that would probably get us a lot more room. Sweet, so its settled,
> we'll do it at Digg WHQ!
>
> On
