eprothro / cassie Goto Github PK

run rake full_spec to see failures.

preparing a statement through the fake session results in a fake prepared statement being put in the statement cache.

If that fake prepared statement is then executed later with a real session, there can be type hinting issues like

Cassandra::Errors::InvalidError:
       Expected 4 or 0 byte int (8)

Only affects test/spec query usage.

to_cql falls over with certain UDTs with exception message like

ArgumentError:
       value must be an instance of Time, ["foo_at", 2017-10-31 12:10:00 -0500] given

Page explaining motivation and some of the "why's"

If cursor_by has been called on a cassie query class, fetch_first will fail, with:

A singleton method has already been defined for `limit`. `with_limit` can't be implemented.
     # ./lib/cassie/statements/statement/limiting.rb:89:in `assert_no_limit_singleton'
     # ./lib/cassie/statements/statement/limiting.rb:70:in `define_limit_singleton'
     # ./lib/cassie/statements/statement/limiting.rb:46:in `with_limit'
     # ./lib/cassie/statements/execution/peeking.rb:12:in `execute'
     # ./lib/cassie/statements/execution/fetching.rb:25:in `fetch'
     # ./lib/cassie/statements/execution/fetching.rb:38:in `block in fetch_first'

• option to disable
• consider forked cluster support for multithreaded servers out of the box (puma, unicorn, passenger) - sync with Cassandra team for best practice.

expect(query.statement).to have_cql_assignment(:field)

expect(query.statement).to have_cql_assignment(:field, value)

expect(query.statement).to have_cql_relation(:field)

expect(query.statement).to have_cql_relation(:field, value)

Would go a long way for clients to be able to stop their testing plane sooner and have faster cassandra query coverage.

cassie schema management keyspace is created with simple replication strategy, if you have a cluster with a multiple DC configuration, the cassie schema tasks will fail.

Workaround:

Attempt to initialize

cassie schema:init

Alter the keyspace manually

Edit the cassie_schema keyspace manually (in cqlsh) to have the proper replication settings.

initialize again

cassie schema:init

type
#=> #<Cassandra::Types::Simple:0x007fed37c33300 @kind=:bigint>

params[i]
#=> nil

params
#=> ["55e05d24-513b-11e7-b6b8-33c23e6e0000", 2017-06-14 14:54:54 -0500, nil, nil, "55e0893e-513b-11e7-bd08-0f7a965973cc", "testuser94517816"]

bound_cql
#=> "INSERT INTO some_table (id, other_id, url, other_url, user_id, username) VALUES (?, ?, ?, ?, ?, ?);"

type
#<Cassandra::Types::Simple:0x007fed37c33300 @kind=:bigint>

type.new(nil)

     TypeError:
       can't convert nil into Integer

would be nice to catch type errors and give more info about what param is the culprit.

When a task dumps the schema, it calls out to cqlsh, but this exepects that the vanilla call to the command without options will just work.

It could use the cluster options to populate options (like auth).

Cassandra::Errors::TimeoutError for non-trivial schemas when running:

• schmea:drop
• schema:reset
• migrate:reset

Cassandra received request and executes successfully, but times out while doing so, so rest of task doesn't run after that failure.

In all cases there should be no harm in simply re-running.

However, probably a good idea to set the query timeout longer for these queries.