A cursory look at the Cassandra 5 stuff didn’t indicate any incompatibility. So
yeah, I think we are likely pretty safe to use the 4.17 driver
Sent from my iPhone
> On Mar 19, 2024, at 3:35 PM, Matt Burgess wrote:
>
> Is it likely now (due to the refactor) that we will simply be able to
>
Hello,
we are trying to run NiFi Registry in Java 11. Receiving the following error:
Text:
>
D:\NiFi\nifi-registry-1.23.2\bin>run-nifi-registry.bat
cmd.exe /C "C:\Program
Is it likely now (due to the refactor) that we will simply be able to
upgrade the driver when Cassandra 5 is GA? Also does anyone use Netflix's
Astyanax [1]?
[1]
https://cassandra.apache.org/doc/stable/cassandra/getting_started/drivers.html#java
On Tue, Mar 19, 2024 at 3:10 PM Mike Thomsen
Realistically, I think we are only likely to see two drivers:
* DataStax
* ScyllaDB
The latter makes a selling point of being a binary compatible, drop-in
replacement for the former.
That's why I don't see a need to have an abstraction layer per se. I think
we only need
Mike,
Thanks for the reply and clarification.
I agree there is no need to maintain support for the DataStax 3 driver
and Java API, any new components should be built on the latest version
of the driver.
What we do need going forward is to avoid, if at all possible, having
a DataStax 4
** we can dump v3 **DRIVER** compatibility, since later 4.X Java drivers
are backward compatible with Cassandra 3
On Tue, Mar 19, 2024 at 2:43 PM Mike Thomsen wrote:
> David,
>
> Before we proceed, I think we should make sure we're all understanding the
> same problem here. Starting with this:
David,
Before we proceed, I think we should make sure we're all understanding the
same problem here. Starting with this:
> I believe the CQL protocol is backwards compatible but the Java API is
not.
> For example "com.datastax.driver.core.Session" is now
>
Hello,
we are trying to run NiFi Registry in Java 11. Receiving the following error:
[cid:373db5b6-713b-443b-8aa3-0aa896934bf5]
Text:
>
All,
I support a Controller Service API abstraction around the Cassandra
Driver. The changes from DataStax 3 to 4 already highlight the need
for that abstraction. The donation of the DataStax Java driver to
Apache [1] also shows the value of providing some level of isolation,
if at all possible.
Matt,
I got that. My point was that the Java changes appear to be a one time
thing that DataStax did to make a better driver with a much more
future-proof API. Since Scylla tracks them as closely as possible, I
suspect that we don't need to plan for a bunch of abstraction to isolate
Java changes.
That was kinda where i got stuck and fell out on my branch/jira. Mike and
I wanted to make a new controller service , without backward compatibility;
and remove the duplicate driver/connection properties found in some of the
processors.
I agree taking out all old stuff and making new controller
The abstraction is to isolate Java API changes, not protocol compatibility.
Changing to the java-driver comes with a number of changes to the code (see
Steven's and my branches), if we can abstract that API it should lead to
more maintainable code in the future by not having to change any
https://opensource.docs.scylladb.com/stable/using-scylla/drivers/cql-drivers/scylla-java-driver.html
Directly quoting Scylla docs here:
> The Scylla Java Driver is a drop-in replacement for the DataStax Java
Driver. As such, no code changes are needed to use this driver.
On Tue, Mar 19, 2024 at
Matt,
I don't think we need to really "abstract above" the drivers because the
Java DataStax driver appears to support 4.X all the way back to 2.X, as
well as the enterprise versions from DataStax
https://docs.datastax.com/en/driver-matrix/docs/java-drivers.html
Similar situation with Scylla.
14 matches
Mail list logo
