Thanks Mathew, We have been trying to do the same and did a quick testing by making the below changes
1. Changed the datastax cassandra-driver-core to version 2.0.1 from 2.0.3. Version 2.0.1 supports 1.2+ ( we user C* 1.2.x.x) that works with CQL3 2. Got rid of the "IF NOT EXISTS" clause ( via exception handling) 3. replaced BATCHSTATEMENTS which is not supported by C* protocol version 1 with BOUNDSTATEMENTS. With init testing done with changed jar, our application could startup with out any errors and we had the keyspace and tables created. I have created an issue in GITHUB to seek some help from Martin as we need to use this plugin as our Product has only Cassandra plugged in as Database. Thanks Ratika On Wednesday, August 20, 2014 1:17:53 AM UTC+5:30, Matthew Howard wrote: > > Hi - no we haven't implemented this yet... we wound up getting sidetracked > by some other priorities. But we are going to need to implement this at > some point. It's been a bit since I've looked into the details but as I > remember there were 2 key changes needed for C* 1.2: > > > 1. C* 2.0 introduced the "IF NOT EXISTS" clause - so in > CassandraStatements.scala > > <https://github.com/krasserm/akka-persistence-cassandra/blob/master/src/main/scala/akka/persistence/cassandra/journal/CassandraStatements.scala> > (both > in snapshot and journal files) that would need to be removed... which > obviously means those will fail if the keyspaces/columnfamilies exist. I > was thinking of just catching the exception in CassandraJournal.scala > > <https://github.com/krasserm/akka-persistence-cassandra/blob/f6c885fe943aaa898a3d191083368ecab6e1ddc0/src/main/scala/akka/persistence/cassandra/journal/CassandraJournal.scala#L27> > (again > would also need the same in CassandraSnapshotStore.scala ) > 2. The Datastax 2.0 driver doesn't support C* 1.2, so that would need > to be downgraded to the 1.0 driver. I believe this means the inserts > currently using the BatchStatement will need to change... this will > probably be the tricky part, although depending on your throughput needs > it > might be fine to just execute the prepared statements without batching. > See > http://www.datastax.com/dev/blog/client-side-improvements-in-cassandra-2-0 > for > a description of the new BatchStatement in the datastax driver. By > looking at the old PreparedStatement you can see the types of changes > that would need to be made. > > Ignore my comments above regarding the composite keys of processor_id and > partition_nr... Cassandra 1.2 should support the composite PK as defined in > this journal. > > So at first glance the changes for C* 1.2 seem not too bad - I would only > be worried about any hidden gotchas that I haven't noticed regarding the > 1.0 driver, and about the potential performance hit of not being able to > use the BatchStatement. > > I don't know when we will take this on, but I'll post back to this thread > when we do. > > > > On Thursday, August 14, 2014 12:35:27 AM UTC-4, [email protected] > wrote: >> >> Hi Mathew, >> >> We also need to use the akka persistence journal plugin for older version >> of Cassandra v 1.2.x, hoever the plugin available works for version 2.0.3 >> or higher. Came across your post, did you happen to implement/tweak the >> journal for older version of Cassandra ? If yes would share it with us or >> let us know what were the tweaks required. Thanks for your help. >> >> --Ratika >> >> On Tuesday, May 6, 2014 12:51:25 AM UTC+5:30, Matthew Howard wrote: >>> >>> Has anyone implemented an akka persistence journal for older versions of >>> Cassandra? I see the current journal is dependent on C* v2.0.3 or higher ( >>> https://github.com/krasserm/akka-persistence-cassandra) but my app is >>> currently on 1.1.9 and we are only actively planning to upgrade to v1.2 >>> (just found this out - I thought we were moving to 2). >>> >>> I'm guessing there isn't one already out there, but thought I'd ask >>> before attempting to implement one. Assuming I would need to implement it >>> (probably a question for Martin directly) any warnings or recommendations? >>> At first glance I'd obviously need to tweak the create >>> keyspace/columnfamily commands (and change the driver), but I'm not seeing >>> anything that appears to be too wildly dependent on C* v2.0.3 features. The >>> handling of the partition_nr seems to be the biggest issue - I'm thinking >>> we could just create the rowkey as a concatenation of the processor_id and >>> partition_nr (e.g. "myprocessor-0", "myprocessor-1", etc... ). But I >>> think/hope? otherwise the composite columns should work the same and I'm >>> not going to get myself into a rabbit hole... >>> >>> Thanks in advance, >>> Matt Howard >>> >>> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
