[ https://issues.apache.org/jira/browse/CASSANDRA-12733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564760#comment-15564760 ]
Alex Petrov commented on CASSANDRA-12733: ----------------------------------------- CI looks good now (had to re-run trunk from my fork, although code is identical). |[3.X |https://github.com/JeremiahDJordan/cassandra/tree/CASSANDRA-12733-3X]|[dtest|http://cassci.datastax.com/job/JeremiahDJordan-CASSANDRA-12733-3X-dtest/]|[utest|http://cassci.datastax.com/job/JeremiahDJordan-CASSANDRA-12733-3X-testall/]| |[trunk|https://github.com/JeremiahDJordan/cassandra/tree/CASSANDRA-12733-trunk]|[dtest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12733-trunk-dtest/]|[utest|https://cassci.datastax.com/view/Dev/view/ifesdjeen/job/ifesdjeen-12733-trunk-testall/]| > Throw an exception if there is a prepared statement id hash conflict. > --------------------------------------------------------------------- > > Key: CASSANDRA-12733 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12733 > Project: Cassandra > Issue Type: Improvement > Components: CQL > Reporter: Jeremiah Jordan > Assignee: Jeremiah Jordan > Priority: Minor > Fix For: 3.x > > > I seriously doubt there is any chance of actually getting two prepared > statement strings that have the same MD5. But there should probably be > checks in QueryProcessor.getStoredPreparedStatement that the query string of > the statement being prepared matches the query string of the ID returned from > the cache when one already exists there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)