> 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/cassandra/ClientOptions
> I was wondering if cassandra has or will ever support eventual constancy > where it keeps both the REMOVE AND the ADD together such until it is on all 3 > replicated nodes and in resolving the consistency would end up with an index > that only has the very last one in the index. Not sure I fully understand but it sounds like you want a transaction, which is not going to happen. Internally when Cassandra updates a secondary index it does the same thing. But it synchronises updates around the same row so one thread will apply the changes at a time. Hope that helps. ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 16/08/2012, at 12:34 PM, "Hiller, Dean" <dean.hil...@nrel.gov> wrote: > 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 this in the future…. > > When using wide row indexes, you frequently have <indexedValue>.<primaryKey> > as the composite key. This means when you have your object like so in the > database > > Activity { > pk: 65 > name: bill > } > > And then two servers want to save it as > > Activity { > pk:65 > name:tim > } > Activity { > pk:65 > name:mike > } > > Each server will remove <bill><65> and BOTH servers will add <tim><65> AND > <mike><65> BUT one of them will really be a lie!!!!! I was wondering if > cassandra has or will ever support eventual constancy where it keeps both the > REMOVE AND the ADD together such until it is on all 3 replicated nodes and in > resolving the consistency would end up with an index that only has the very > last one in the index. > > Thanks, > Dean >
