question

@rkagan_146583 The DSE drivers provide full access to DataStax Enterprise functionality and features. At the time of writing, the additional functionality that DSE drivers have over Cassandra drivers are DSE Graph fluent API and DSE Advanced Security features.

We will continue to add more features to the DSE drivers in the future so we recommend switching to make it easier to take advantage of DSE optimisations and other upcoming features. If you haven't already seen these, check out the following documents:

• Developing applications with DataStax drivers
• Using DSE Search with the DataStax drivers

I am very interested in this as well and found Erick's reply to be ... disappointing.

What has been helpful is to follow the links to the DataStax Java Driver for Apache Cassandra 4.2 Upgrade Guide. File-based configs can be very compelling if your environment already works that way. The new object mapper also looks interesting.

For me, the changes with graph in DSE driver are interesting too.

Hi:

I'd be willing to donate the porting tool that modifies the source code and configs if someone can provide the analogous classes for DSE Java Driver 2.x (these classes used by DSE Java Driver 1.8.x):

com.datastax.driver.core.BoundStatement

com.datastax.driver.core.Cluster

com.datastax.driver.core.ColumnDefinitions

com.datastax.driver.core.ColumnDefinitions.Definition

com.datastax.driver.core.ColumnMetadata

com.datastax.driver.core.ConsistencyLevel

com.datastax.driver.core.ExecutionInfo

com.datastax.driver.core.Host

com.datastax.driver.core.KeyspaceMetadata

com.datastax.driver.core.Metadata

com.datastax.driver.core.PreparedStatement

com.datastax.driver.core.querybuilder.QueryBuilder

com.datastax.driver.core.querybuilder.Select

com.datastax.driver.core.RegularStatement

com.datastax.driver.core.ResultSet

com.datastax.driver.core.ResultSetFuture

com.datastax.driver.core.Row

com.datastax.driver.core.Session

com.datastax.driver.core.SimpleStatement

com.datastax.driver.core.Statement

com.datastax.driver.core.TableMetadata

Hi all, I am the PM for the drivers and want to give some details here, both into the upgrade specifics and to the design decisions that were made along the way.

First, we adhere to semantic versioning in the drivers, so we never break the API compatibility in minor revs and only do so in major version bumps. The DSE Java Driver 1.x to 2.x represented an opportunity for us to remove sharp edges that customers have continuously stumbled upon throughout the years and to deliver a more opinionated API, ultimately with the goal of ushering users down a path of successful integration in their applications. This resulted in the fact that the 2.x version of the DSE Java Driver is not binary compatible with the 1.x version.

For DSE Search capability there are not any significant changes from DSE Java Driver 1.x to 2.x. You want to do things as you typically do, passing the solr_query directly in your statements. Also regarding DSE Graph, please continue to let us know where we can improve documentation there, we know we missed some things when we first released DSE Java Driver 2.x ( driver graph docs ).

Remember that all things in the OSS Java Driver 4.x upgrade guide also apply to the DSE Java Driver 2.x.

Below is a list of the most prominent changes from DSE Java Driver 1.x to 2.x.

1. File Based Configuration

As noted in the previous comments, this is one of the biggest changes that you will come across when you first get your hands on the new driver. In DSE Java Driver 2.x you can configure everything in a dse-reference.conf file or via any other file and format that you specify on your classpath. This is a more flexible, clear, and common technique for applications than programmatically configuring the driver. For example, this enabled us to easily build the Spring Boot Starter with which you can configure the Java Driver directly alongside your Spring application properties. This technique also removes the need to re-compile your application every time you make a driver config change and there are many options now that can be dynamically reloaded from the file.

That said, we know there are many tools that have their own configuration mechanisms and programmatically doing things may still be the most convenient path for those instances. Because of this we also expose a programmatic configuration API which we will continue to improve to alleviate issues that have been brought to our attention since releasing the new driver.

2. Reactive Request Processor ( docs )

The DSE Java Driver 2.x introduces the new executeReactive method for those using reactive programming. Details on that are here https://docs.datastax.com/en/developer/java-driver-dse/2.2/manual/core/reactive/.

3. DSE Load Balancing Policy

The default DseLoadBalancingPolicy does away with the old chaining mechanism of the 1.x load balancing policies. We did this because the policies would behave differently depending on the order in which they were chained and we saw that the large majority of our users were going with Token Aware + DC Aware and sometimes Latency Aware. The DseLoadBalancingPolicy uses a more proactive mechanism to sense busy nodes and uses an algorithm that more effectively load balances requests when compared to round robin, resulting in better latencies. All of this is built-in, with minimal configuration exposed for ease of use. One thing to note is that we now require you to pass the local data center that the driver should connect to, this decision was made to make things explicit and to remove confusion and misconfiguration caused by the implicit assumption by the driver of the local data center.

4. Bye Bye Guava

The Guava dependency in the DSE Java Driver 1.x caused issues for users ( example ). We are no longer leaking that and instead use Java 8+'s CompletionState rather than Guava's ListenableFuture in DSE Java Driver 2.x.

5. Execution Profiles ( docs )

If you have queries that behave differently or that should go to different data centers depending on the DSE Advanced Workload in use, these execution profiles can be a nice way to enforce that behavior at the application level. These are a net new feature of DSE Java Driver 2.x.

6. Prepared Statement Cache

In DSE Java Driver 1.x you get a warning when preparing a query more than once and the driver would make a round trip to the server.

In DSE Java Driver 2.x we have a prepared statement cache such that if you prepare a query more than once, the internal cache is checked and saves the round trip to the server.

7. Proper Protocol Negotiation during upgrade

In DSE Java Driver 1.x it is a best practice to pin your client protocol version in the driver to the protocol version supported by the DSE version that you are upgrading from. This is because the driver is using the protocol version of the first successful contact point that it connects to. This sharp edge is removed in DSE Java Driver 2.x and now we consider all of the nodes in the cluster while deciding the protocol version to connect with, removing the need to set it explicitly in the application and making server side upgrades safer.

8. A true request timeout

In DSE Java Driver 1.x statement.setReadTimeoutMillis was the timeout per node tried, meaning, if you use speculative executions or if the retry policy kicks in, that timeout is applied to _each_ query. Now in DSE Java Driver 2.x statement.setTimeout spans the entire request including retries, spec exec, throttling and actually does what you likely thought the previous setting was doing in the first place.

9. Dual Result Set APIs

In DSE Java Driver 1.x there was only a single ResultSet. While this may seem convenient, there are subtle problems with the paging semantics there such that when you execute a query asynchronously the paging is actually done synchronously. We split those out in DSE Java Driver 2.x and now have a ResultSet and AsyncResultSet so that you get a truer, expected synchronous or asynchronous behavior when paging.

10. Statements are immutable

The main advantage here is that it makes statements automatically thread-safe: you don’t need to worry anymore about sharing them or reusing them between asynchronous executions.

11. CQL to Java type mappings ( docs )

We took advantage of the Java 8 types here and this is something to be aware of.

12. Reconnect on Initialization

Using Kubernetes? Reconnection is now possible at startup: if no contact point is reachable, the driver will retry at periodic intervals (controlled by the reconnection policy) instead of throwing an error. To turn this on, set advanced.reconnect-on-init = true.

Hope this helps,

Chris