[ 
https://issues.apache.org/jira/browse/CASSANDRA-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14325708#comment-14325708
 ] 

Sylvain Lebresne commented on CASSANDRA-8818:
---------------------------------------------

What happens is that you should wait for schema propagation (of the keyspace) 
before issuing the table creation. Now, while it's possible to do that 
manually, the theory is that your driver should handle that and so I suspect 
the C# driver either don't do that, or doesn't do it properly (the fact it 
works with cqlsh supports the theory that it's not a C* problem; the fact that 
it works if you use prepared statements is likely just due to the fact that the 
time it takes to prepare the statement is enough for the schema to propagate). 
You'll want to check that with the C# driver authors (see the "getting help" 
section of https://github.com/datastax/csharp-driver) as drivers are separate 
from the Apache Cassandra project and thus not tracked here. 

> Creating keyspace then table fails with non-prepared query
> ----------------------------------------------------------
>
>                 Key: CASSANDRA-8818
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8818
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Drivers (now out of tree)
>            Reporter: Jonathan New
>
> Hi, I'm not sure if this is a driver or cassandra issue, so please feel free 
> to move to the appropriate component. I'm using C# on mono (linux), and the 
> 2.5.0 cassandra driver for C#.  We have a cluster of 3 nodes, and we noticed 
> that when we created a keyspace, then a table for that keyspace in quick 
> succession it would fail frequently. I put our approximate code below.
> Additionally, we noticed that if we did a prepared statement instead of just 
> executing the query, it would succeed. It also appeared that running the 
> queries from a .cql file (outside of our C# program) would succeed as well. 
> In this case with tracing on, we saw that it was "Preparing statement".
> Please let me know if you need additional details. Thanks!
> {noformat}
> var pooling = new PoolingOptions ()
>     .SetMaxConnectionsPerHost (HostDistance.Remote, 24) 
>     .SetHeartBeatInterval (1000);
> var queryOptions = new QueryOptions ()
>     .SetConsistencyLevel(ConsistencyLevel.ALL);
> var builder = Cluster.Builder ()
>     .AddContactPoints (contactPoints)
>     .WithPort (9042)
>     .WithPoolingOptions (pooling)
>     .WithQueryOptions (queryOptions)
>     .WithQueryTimeout (15000);
> String keyspaceQuery = "CREATE KEYSPACE IF NOT EXISTS metadata WITH 
> replication = {'class': 'SimpleStrategy', 'replication_factor': '3'}  AND 
> durable_writes = true;";
> String tableQuery = "CREATE TABLE IF NOT EXISTS  metadata.patch_history (
>   metadata_key text,
>   patch_version int,
>   applied_date timestamp,
>   patch_file text,
> PRIMARY KEY (metadata_key, patch_version)
> ) WITH CLUSTERING ORDER BY (patch_version DESC)
>   AND bloom_filter_fp_chance = 0.01
>   AND caching = 'KEYS_ONLY'
>   AND comment = ''
>   AND compaction = {'min_threshold': '4', 'class': 
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 
> 'max_threshold': '32'}
>   AND compression = {'sstable_compression': 
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
>   AND dclocal_read_repair_chance = 0.1
>   AND default_time_to_live = 0
>   AND gc_grace_seconds = 864000
>   AND memtable_flush_period_in_ms = 0
>   AND read_repair_chance = 0.0
>   AND speculative_retry = '99.0PERCENTILE';";
> using (var session = cluster.Connect ()) {
>   session.Execute(keyspaceQuery);
>   session.Execute(tableQuery);
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to