> 1. Can playOrm be listed on cassandra's list of ORMs? It supports a JQL/HQL
> query on a trillion rows in under 100ms (partitioning is the trick so you can
> JQL a partition)
No sure if we have an ORM specific page. If it's a client then feel free to add
it to http://wiki.apache.org/cassandr
1. Can playOrm be listed on cassandra's list of ORMs? It supports a JQL/HQL
query on a trillion rows in under 100ms (partitioning is the trick so you can
JQL a partition)
2. Many applications have a common indexing problem and I was wondering if
cassandra has or could have any support for t
> Is there a way to create a slice query that returns all columns where the
> _second_ component is A?
No.
You can only get a contiguous slice of columns.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelastpickle.com
On 16/08/2012, at 7:21 AM, Mike Hugo
> WARN 09:02:38,534 Unable to instantiate cache provider
> org.apache.cassandra.cache.SerializingCacheProvider; using default
> org.apache.cassandra.cache.ConcurrentLinkedHashCacheProvider@5d59054d instead
Happens when JNA is not in the path. Nothing to worry about when using the
sstableloader.
Quoting false is correct from my reading of the Antlr grammar.
Constant terms are either strings, UUID, int or long.
I'm sure someone from DS will pickup the comment you made on the post and fix
the example.
Cheers
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.
> Is there anything to do before that? like drain or flush?
For a clean shutdown I do
nodetool -h localhost disablethrift
nodetool -h localhost disablegossip && sleep 10
nodetool -h localhost drain
then kill
> Would you recommend that? If I do it, how often should I do a full snapshot,
> and h
You cannot do that in a single query.
The order of columns in output is the order they are stored in. And the API can
only return a contiguous range of columns.
In this case I would get the larger slice and then discard columns client side.
Or build a second row that has the order of the col
Hello,
Given a row like this
"key1" => (A:A:C), (A:A:B), (B:A:C), (B:C:D)
Is there a way to create a slice query that returns all columns where the
_second_ component is A? That is, I would like to get back the following
columns by asking for columns where component[0] = * and component[1] = A
thanks a lot for the info
On Wed, Aug 15, 2012 at 10:31 AM, Jim Cistaro wrote:
> I have not viewed the code, but it would seem that replace_token does
> not "remove token", because that would spread the data and then "unspread"
> it when the new node joins. But like I said, I have not read the
I have not viewed the code, but it would seem that replace_token does not
"remove token", because that would spread the data and then "unspread" it when
the new node joins. But like I said, I have not read the code.
>From our standpoint, we want the tokens to stay the same when possible due to
aaron,
i understand Ruby client automatically re-connects.
thanks,satoshi
--- On Mon, 2012/8/13, aaron morton wrote:
My rough understanding of the ruby code is that it auto connects if necessary
when you make a request.
i.e. your get turns into a _multiget call here
https://github.com/twitter/
Hi,
we are trying to use SSTableLoader to bootstrap a new 7-node cassandra (v.
1.0.10) cluster with the snapshots taken from a 3-node cassandra cluster. The
new cluster is in a different data centre.
After reading the articles at
[1] http://www.datastax.com/dev/blog/bulk-loading
[2]
http://
Hi,
I was following the examples on this page:
http://www.datastax.com/dev/blog/whats-new-in-cql-3-0#comment-116250
In the example, a table was created as follows:
CREATE TABLE altercations (
instigator text,
started_at timestamp,
ships_destroyed int,
energy_used flo
considering there is this minor "old node hanging around" issue, would the
old T-1 approach sound more attractive?
that way you don't necessarily have to remove the dead token immediately,
but could come back the next day, or even a week later. T-1 would behave
essentially the same in terms of par
ok, I see, the cassandra.replace_token setting essentially executes the
manual removeToken step. so the dead node should be removed.
is this the "old node hanging around" issue that you described?
https://issues.apache.org/jira/browse/CASSANDRA-3259
looks this JIRA is fixed in 1.0x already, so
15 matches
Mail list logo