the-real-blackh / cassandra-cql Goto Github PK

As Cassandra's documentation [1], Code [2][3], and Jira comments [4] indicate, SERIAL and LOCAL_SERIAL are valid consistency levels only for reads, not for writes. Executing writes with SERIAL or LOCAL_SERIAL result in errors described in [2] and [3] (I have validated this in my experiments). I suggest that this note on consistency levels be included in the documentation. A better alternative is to throw a type error or an exception if writes are attempted with the aforementioned consistency levels.

More importantly, the current implementation of executeTrans, which attempts a CAS operation with SERIAL consistency level, is incorrect; it always fails with [2] or [3] error. If the intention is to allow CAS to succeed only if the write is applied to all replicas, then the appropriate consistency level is ALL. Alternatively, given that Cassandra's CAS is parameterized on the consistency level for the write, why not parameterize executeTrans too?

Note that setting the consistency level of a CAS to ALL doesn't guarantee serializability. All it says is that the CAS operation returns true if and only if the write operation succeeded on all replicas . It may so happen that the write operation may fail on some replicas, resulting in the failure of CAS, but the write is still committed on some replicas. As Cassandra's documentation [5] indicates, the only way to guarantee serializability in the event a CAS failure is to run all subsequent reads on the modified items with SERIAL isolation level.

The SERIAL and LOCAL_SERIAL levels also serve another purpose: they control whether a CAS operation is serialized wrt CAS operations across all data centers (SERIAL, the default behavior), or only wrt CAS operations in the current data center (LOCAL_SERIAL). In CQL binary protocol v3, this can be specified via a special flag called serial_consistency (cf. [6] and [7]). Ideally, executeTrans should be parametric on the value of this flag too.

1. http://docs.datastax.com/en/cassandra/2.1/cassandra/dml/dml_config_consistency_c.html , http://datastax.github.io/python-driver/api/cassandra/query.html#cassandra.query.Statement.serial_consistency_level
2. https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L355
3. https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ConsistencyLevel.java#L369
4. https://issues.apache.org/jira/browse/CASSANDRA-8051?focusedCommentId=14516041&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14516041
5. http://www.datastax.com/dev/blog/cassandra-error-handling-done-right
6. https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v3.spec#L370
7. https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v3.spec#L420

Hello!

I'm having a bit of trouble running the example code on my system. I've disabled firewall, I've stood up a simple server with nc, and yet still it returns the same erorr message when running the code:

example.hs: CassandraIOException recv: does not exist (Connection refused)

It doesn't even open a connection to the port... at least as far as I can tell. I think it has to do with IPv6 support; specifically, the need to lookup "localhost" as an IPv4 address... but I'm unable to figure out the code having to do with address lookup. I've also tried 127.0.0.1 and 0.0.0.0 with no luck. I wish this were an easier bug to describe — the lack of stack traces makes this a little difficult to report.

Wreaks havoc with many Docker images that have base-4.8.1.0 pre-installed.

Is it possible to support a newer stack resolver? Currently only able to build on lts-6.35 (from limited testing).

I would love to help out doing this, but I suspect I would be needing a lot of hand holding while doing so.

Unless I'm mistaken, there's no way to close all the connections in a pool.

This would be really useful as in my case I want to write some tests that run in isolated keyspaces which necessitates new pools each time one is created.

Support Records/UDTs

Upgrade Travis script to build all recent versions of haskell. Also have it install Cassandra and run all the tests.

Would you consider replacing the MonadCatchIO-mtl dependency with MonadCatchIO-transformers? The latter being far more ubiquitous and usable without functional dependencies.

It would be great if it was possible to use the hackage with haskell platform 7.8.3

There is a problem currently because of cassandra-cql => base>=4.5.0.0 && <4.7.0.0)

Sorry for rising this as a issue, but it is a bit hard to figure out how to use this library.

root@b3e0266f401c:/# nodetool ring

Datacenter: SearchAnalytics
==========
Address     Rack        Status State   Load            Owns                Token                                       

172.17.0.2  rack1       Up     Normal  485.95 KB       ?                   -2758875854119677886     

{-# LANGUAGE OverloadedStrings #-}

import Data.UUID
import qualified Data.Text as T

import Database.Cassandra.CQL
import Control.Monad.IO.Class

import Data.Maybe

getOneSong :: Query style UUID (UUID)
getOneSong = query "select customer from status_by_customer where customer = ?"

test = do
    pool <- newPool [("172.17.0.2","")] "test_data" Nothing
    runCas pool $ do
        executeRows ANY getOneSong (fromJust $ fromString "c2cc10e1-57d6-4b6f-9899-38d972112d8c")

But I always get

failed to create a session due to temporary error (will retry) : NoAvailableServers

if I set the server to ("172.17.0.2", "b3e0266f401c"), the following error will rise:

failed to create a session due to permanent error (will rethrow) : getAddrInfo: does not exist (Servname not supported for ai_socktype)

And I am pretty sure I have exported all the port, that needed to connect to Cassandra, as my other programs are working fine with this docker.

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                                                                                                                      NAMES
b3e0266f401c        docker_cassandra    "/usr/local/bin/dse-e"   12 days ago         Up 50 minutes       4040/tcp, 7000/tcp, 7077/tcp, 7080-7081/tcp, 8012/tcp, 8090/tcp, 8983-8984/tcp, 9042/tcp, 9160/tcp, 9290/tcp, 10000/tcp, 50030/tcp, 50060/tcp, 61621/tcp   my-dse

Would you please show me an example that how to use this library to connect to Cassandra ?

Do you have any plans to support protocol version 2? I'd like to use conditional updates but they are only supported by v2.