Matt/David, I got some time this morning to take a crack at directly migrating it over to the DataStax 4.17 driver. Definitely got a lot of work to do, but so far I haven't hit any real snags. This is a branch that reverts the commit to remove the cassandra bundle and reuses the existing features as a foundation. From what I'm seeing so far (feels like I'm about 25% done) it should be doable to reuse the existing bundle, but rename it to the "CQL Bundle" and just add a second controller service for Scylla that is otherwise 100% the same codewise.
On Tue, Mar 19, 2024 at 6:41 PM Mike Thomsen <mikerthom...@gmail.com> wrote: > 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 <mattyb...@apache.org> wrote: > > > > 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 <mikerthom...@gmail.com> > wrote: > >> > >> 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 "DataStaxConnectionProviderImpl" and > >> "ScyllaDBConnectionProviderImpl" with the difference being which jar is > >> imported by maven. > >> > >> On Tue, Mar 19, 2024 at 2:59 PM David Handermann < > >> exceptionfact...@apache.org> wrote: > >> > >>> 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 dependency in the Controller Service API. > >>> > >>> One example of this is the WebClientServiceProvider interface. That > >>> Controller Service API does not have any third-party dependencies. The > >>> Controller Service implementation, StandardWebClientServiceProvider, > >>> has a dependency on OkHttp to implement HTTP communication. That is > >>> the kind of abstraction that would be ideal, and I believe that also > >>> aligns with what Matt has described. > >>> > >>> Regards, > >>> David Handermann > >>> > >>> On Tue, Mar 19, 2024 at 1:45 PM Mike Thomsen <mikerthom...@gmail.com> > >>> wrote: > >>>> > >>>> ** 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 <mikerthom...@gmail.com> > >>> wrote: > >>>> > >>>>> 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 > >>>>>> "com.datastax.oss.driver.api.core.session.Session" and there is no > >>> more > >>>>>> "Cluster" class. Might be fairly trivial to fix though, if that's > >> the > >>>>> path > >>>>>> of least resistance. > >>>>> > >>>>> From what I've learned using Cassandra 3 and 4 in my day job and > >>> reading > >>>>> up on this stuff for the sake of discussion, that all tracks. We used > >>> the > >>>>> ~4.11 driver in Spring Boot on both v3 and v4 clusters without issue > >>> during > >>>>> an upgrade. So I don't see any reason to factor in the "changes from > >>>>> DataStax 3 to 4" since the changes were likely a one-off decision > >>> meant to > >>>>> position the driver for better future support and stability. > >>>>> > >>>>> TL;DR, we can dump v3 compatibility and the only thing our users will > >>>>> notice is if we make the controller service totally incompatible with > >>> the > >>>>> one they're already using which is something we can actively avoid. > >>>>> > >>>>> On Tue, Mar 19, 2024 at 2:00 PM David Handermann < > >>>>> exceptionfact...@apache.org> wrote: > >>>>> > >>>>>> 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. > >>>>>> > >>>>>> I have not taken a close look at the Matt's branch, and the details > >> of > >>>>>> the abstraction are important, but having the abstraction can be > >>>>>> useful to avoid getting back to this same situation. > >>>>>> > >>>>>> Regards, > >>>>>> David Handermann > >>>>>> > >>>>>> [1] https://github.com/apache/cassandra-java-driver/ > >>>>>> > >>>>>> On Tue, Mar 19, 2024 at 12:37 PM Mike Thomsen < > >> mikerthom...@gmail.com > >>>> > >>>>>> wrote: > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> On Tue, Mar 19, 2024 at 11:07 AM Steven Matison < > >>>>>> steven.mati...@gmail.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> 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 > >> service > >>>>>> makes > >>>>>>>> most sense. 4.x and 5.x should be mostly backwards compatible > >> to > >>>>>> 2&3.x > >>>>>>>> with how it’s used within current processors. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Mar 19, 2024 at 10:49 AM Matt Burgess < > >>> mattyb...@apache.org> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> 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 > >>>>>>>>> processors, just the controller service implementation. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, Mar 19, 2024 at 10:14 AM Mike Thomsen < > >>>>>> mikerthom...@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>> > >> > 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 10:13 AM Mike Thomsen < > >>>>>> mikerthom...@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> 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. When I looked at the > >> driver, > >>> it > >>>>>>>> appeared > >>>>>>>>>> to > >>>>>>>>>>> copy verbatim the entire public API of that driver. So I > >>> think > >>>>>> before > >>>>>>>>> we > >>>>>>>>>>> dive into abstractions, it's worth doing a bit more > >>> validation > >>>>>> of > >>>>>>>> these > >>>>>>>>>>> details. IMHO, this might be a much lighter lift than > >>>>>> anticipated. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Mon, Mar 18, 2024 at 4:30 PM Matt Burgess < > >>>>>> mattyb...@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Totally agree, that's what my branch does (see link in > >>> previous > >>>>>>>>> email). > >>>>>>>>>>>> The > >>>>>>>>>>>> more I work with it, the more I think I can abstract it > >>>>>> further from > >>>>>>>>>> their > >>>>>>>>>>>> JDBC-like API but I started with a bunch of delegate > >>> classes > >>>>>> then I > >>>>>>>>>> figure > >>>>>>>>>>>> I'll see where I can consolidate to more abstract > >>> concepts. If > >>>>>> I > >>>>>>>> don't > >>>>>>>>>>>> have > >>>>>>>>>>>> to support Cassandra 3 with the new API, so much the > >>> better. > >>>>>>>>>>>> > >>>>>>>>>>>> Regards, > >>>>>>>>>>>> Matt > >>>>>>>>>>>> > >>>>>>>>>>>> On Mon, Mar 18, 2024 at 4:14 PM David Handermann < > >>>>>>>>>>>> exceptionfact...@apache.org> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Matt et al, > >>>>>>>>>>>>> > >>>>>>>>>>>>> It is good to see the background effort on moving > >>> Cassandra > >>>>>>>>>>>>> capabilities in a supportable direction. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I think new Cassandra components will require a > >>> significant > >>>>>>>>> departure > >>>>>>>>>>>>> from current Controller Service abstractions. Right > >> now, > >>> the > >>>>>>>>> existing > >>>>>>>>>>>>> service interface does not provide a clean abstraction > >>> from > >>>>>> the > >>>>>>>>>>>>> Cassandra library, which is part of the reason for the > >>>>>> current > >>>>>>>>>>>>> coupling to the legacy driver version. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Following up from Joe's comments, it seems like the > >>> cleanest > >>>>>> way > >>>>>>>>>>>>> forward is to deprecate the current bundle on the 1.x > >>>>>> branch, and > >>>>>>>>>>>>> remove the current bundle from the main branch. That > >> will > >>>>>> provide > >>>>>>>> a > >>>>>>>>>>>>> clean slate for new Service and Processor > >>> implementations, > >>>>>> without > >>>>>>>>>>>>> concern for uncertain compatibility questions. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> David Handermann > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Mon, Mar 18, 2024 at 2:35 PM Matt Burgess < > >>>>>>>> mattyb...@apache.org> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> What do y'all think about removing the individual > >>>>>> connection > >>>>>>>>>>>> properties > >>>>>>>>>>>>>> from the Cassandra processors for NiFi 2.0 and > >>> requiring a > >>>>>>>>>>>>>> CassandraSessionProvider instead? I think we started > >>> doing > >>>>>> that > >>>>>>>>>>>> elsewhere > >>>>>>>>>>>>>> (Elasticsearch maybe?), I noticed duplicate code in > >> the > >>>>>>>>>>>>>> CassandraSessionProvider and > >>> AbstractCassandraProcessor, > >>>>>> if we > >>>>>>>>> keep > >>>>>>>>>>>> those > >>>>>>>>>>>>>> properties I can refactor them into a utility class. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> Matt > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 2:44 PM Steven Matison < > >>>>>>>>>>>> steven.mati...@gmail.com > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I got through quite a bit of work to enable 4.x… > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The 3.x pieces that were not backwards compatible > >> is > >>>>>> very edge > >>>>>>>>> use > >>>>>>>>>>>>> case and > >>>>>>>>>>>>>>> could have been done slightly differently but with > >>> work > >>>>>>>> around. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>> https://github.com/steven-matison/nifi/tree/nifi-10120-1 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 2:30 PM Matt Burgess < > >>>>>>>>>> mattyb...@apache.org> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Oops used the wrong email address so if there > >> have > >>> been > >>>>>>>>>> responses > >>>>>>>>>>>> to > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> Cassandra thread since mine I missed them, my > >> bad! > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 2:00 PM Matt Burgess < > >>>>>>>>>> mattyb...@gmail.com > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I believe the CQL protocol is backwards > >>> compatible > >>>>>> but the > >>>>>>>>>> Java > >>>>>>>>>>>>> API is > >>>>>>>>>>>>>>>>> not. For example > >>> "com.datastax.driver.core.Session" > >>>>>> is now > >>>>>>>>>>>>>>>>> > >>> "com.datastax.oss.driver.api.core.session.Session" > >>>>>> and > >>>>>>>> there > >>>>>>>>>> is > >>>>>>>>>>>> no > >>>>>>>>>>>>> more > >>>>>>>>>>>>>>>>> "Cluster" class. Might be fairly trivial to fix > >>>>>> though, if > >>>>>>>>>>>> that's > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> path > >>>>>>>>>>>>>>>>> of least resistance. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 1:40 PM Joe Witt < > >>>>>>>>> joe.w...@gmail.com> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Matt > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I dont know a ton about Cassandra but when I > >>> looked > >>>>>> at > >>>>>>>>>>>>> client/driver > >>>>>>>>>>>>>>>> notes > >>>>>>>>>>>>>>>>>> for 4+ it said it was compatible all the way > >>> back > >>>>>> to 3.x. > >>>>>>>>>> Not > >>>>>>>>>>>>> sure > >>>>>>>>>>>>>>>> what > >>>>>>>>>>>>>>>>>> that means but it surely seems worth > >> exploring. > >>>>>> Also I > >>>>>>>>> dont > >>>>>>>>>>>> know > >>>>>>>>>>>>> if > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> 4.x drivers get rid of the vulnerable bits. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 10:39 AM Matt Burgess > >> < > >>>>>>>>>>>>> mattyb...@apache.org> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> At the very least we should upgrade to > >>> Cassandra > >>>>>>>> 3.11.6: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>> https://github.com/apache/cassandra/blob/cassandra-3.11.16/CHANGES.txt > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 1:31 PM Matt > >> Burgess < > >>>>>>>>>>>>> mattyb...@apache.org> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> If the community agrees to get rid of > >>> Cassandra > >>>>>> 3 > >>>>>>>>> that'll > >>>>>>>>>>>>> save me > >>>>>>>>>>>>>>>>>> effort > >>>>>>>>>>>>>>>>>>>> on the refactor after I add Cassandra 4 :) > >>>>>> Otherwise > >>>>>>>>>> those > >>>>>>>>>>>>>>>>>>>> vulnerabilities would only be in a "new" > >>>>>> Cassandra 3 > >>>>>>>>>>>> services > >>>>>>>>>>>>> NAR > >>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>>> would not be included in the convenience > >>> binary. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 1:28 PM Joe Witt < > >>>>>>>>>>>> joe.w...@gmail.com> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Mike, Matt, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Happy to hear you both have active > >> efforts > >>> or > >>>>>> are > >>>>>>>>>>>> interested > >>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> doing > >>>>>>>>>>>>>>>>>>> so. > >>>>>>>>>>>>>>>>>>>>> Can you help me understand more > >>> specifically > >>>>>> what > >>>>>>>> that > >>>>>>>>>>>> means > >>>>>>>>>>>>> for > >>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>> current set of components? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> The CVE hits are concerning and long > >>> standing. > >>>>>>>>>> Supporting > >>>>>>>>>>>>>>>> Cassandra > >>>>>>>>>>>>>>>>>> 3 > >>>>>>>>>>>>>>>>>>>>> implies the current set of dependencies > >>> would > >>>>>> remain > >>>>>>>>> too > >>>>>>>>>>>>> right? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Is the current set of components we have > >>> ones > >>>>>> we > >>>>>>>> want > >>>>>>>>> to > >>>>>>>>>>>>> retain? > >>>>>>>>>>>>>>>> We > >>>>>>>>>>>>>>>>>>>>> certainly need Cassandra components - but > >>> are > >>>>>> the > >>>>>>>> ones > >>>>>>>>>> we > >>>>>>>>>>>>> have > >>>>>>>>>>>>>>> now > >>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>> right ones? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>>>>>>> Joe > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 10:25 AM Matt > >>> Burgess < > >>>>>>>>>>>>>>>> mattyb...@apache.org> > >>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I'm actively working this, I pushed my > >>>>>> branch up > >>>>>>>> in > >>>>>>>>>> case > >>>>>>>>>>>>> anyone > >>>>>>>>>>>>>>>>>> wants > >>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>> take a look [1]. The idea is to > >> abstract > >>> the > >>>>>>>>> Cassandra > >>>>>>>>>>>> API > >>>>>>>>>>>>> "up > >>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>> couple > >>>>>>>>>>>>>>>>>>>>>> levels" and provide implementations for > >>>>>> Cassandra > >>>>>>>> 3, > >>>>>>>>>> 4, > >>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> eventually > >>>>>>>>>>>>>>>>>>>>> 5. > >>>>>>>>>>>>>>>>>>>>>> For JDBC-like interfaces this is a PITA > >>>>>> because of > >>>>>>>>> the > >>>>>>>>>>>> API > >>>>>>>>>>>>>>>>>> (Statement, > >>>>>>>>>>>>>>>>>>>>>> PreparedStatement, BoundStatement, > >>> ResultSet, > >>>>>>>> etc.) > >>>>>>>>>> but > >>>>>>>>>>>> I'm > >>>>>>>>>>>>>>>> hoping > >>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>> can > >>>>>>>>>>>>>>>>>>>>>> find a common pattern for abstracting > >> the > >>>>>>>>> third-party > >>>>>>>>>>>>> library > >>>>>>>>>>>>>>>>>>>>>> implementation and API from the NiFi > >>>>>> component > >>>>>>>>>>>> (Processor, > >>>>>>>>>>>>>>>>>>>>>> ControllerService, etc.) API. I think > >>> we're > >>>>>> doing > >>>>>>>>>>>> something > >>>>>>>>>>>>>>>> similar > >>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>> Kafka? > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>>>> Matt > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> [1] > >>>>>> https://github.com/mattyb149/nifi/tree/cassy4 > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On Fri, Mar 15, 2024 at 8:43 AM Mike > >>> Thomsen > >>>>>> < > >>>>>>>>>>>>>>>>>> mikerthom...@gmail.com> > >>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> That’s been on my todo list for a > >>> little > >>>>>> while > >>>>>>>> but > >>>>>>>>>>>> things > >>>>>>>>>>>>>>> kept > >>>>>>>>>>>>>>>>>>> coming > >>>>>>>>>>>>>>>>>>>>> up. > >>>>>>>>>>>>>>>>>>>>>>> I think I could get started on that > >>> now. > >>>>>> Based > >>>>>>>> on > >>>>>>>>> my > >>>>>>>>>>>>> initial > >>>>>>>>>>>>>>>>>>> research > >>>>>>>>>>>>>>>>>>>>> it > >>>>>>>>>>>>>>>>>>>>>>> appears that scylla uses the exact > >> same > >>>>>> api as > >>>>>>>>>>>> datastax > >>>>>>>>>>>>> so > >>>>>>>>>>>>>>>>>>> supporting > >>>>>>>>>>>>>>>>>>>>>> both > >>>>>>>>>>>>>>>>>>>>>>> in a cql bundle should theoretically > >> be > >>>>>> fairly > >>>>>>>>> easy. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Sent from my iPhone > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On Mar 14, 2024, at 6:18 PM, Joe > >>> Witt < > >>>>>>>>>>>>> joew...@apache.org> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Team, > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Cassandra remains a really > >> important > >>>>>> system to > >>>>>>>>> be > >>>>>>>>>>>> able > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>> send > >>>>>>>>>>>>>>>>>>> data > >>>>>>>>>>>>>>>>>>>>> to. > >>>>>>>>>>>>>>>>>>>>>>>> However, it seems like we've not > >>>>>> maintained > >>>>>>>>> these > >>>>>>>>>>>>> well. We > >>>>>>>>>>>>>>>>>> have > >>>>>>>>>>>>>>>>>>>>> what > >>>>>>>>>>>>>>>>>>>>>>>> appears to be at least a full > >>> generation > >>>>>>>> behind > >>>>>>>>> on > >>>>>>>>>>>>> client > >>>>>>>>>>>>>>>>>> versions > >>>>>>>>>>>>>>>>>>>>> (we > >>>>>>>>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>>>>>>>>> on 3x vs 4x which is the latest > >>> stable > >>>>>> with 5x > >>>>>>>>>>>>> apparently > >>>>>>>>>>>>>>>>>> coming > >>>>>>>>>>>>>>>>>>>>>>> shortly). > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> We have components to send data, > >>> query > >>>>>> data, > >>>>>>>> and > >>>>>>>>>> use > >>>>>>>>>>>>>>>> Cassandra > >>>>>>>>>>>>>>>>>> as > >>>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>>>> cache > >>>>>>>>>>>>>>>>>>>>>>>> store. We have older mechanisms > >> for > >>>>>> json/avro > >>>>>>>>> and > >>>>>>>>>>>>> publish > >>>>>>>>>>>>>>>>>>>>> mechanisms > >>>>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>> records. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> The libraries we do have depend on > >>>>>> outdated > >>>>>>>>>>>> versions of > >>>>>>>>>>>>>>> Guava > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> result > >>>>>>>>>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>>>>>>>>>> many CVE hits. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I am inclined to think we should > >>>>>> deprecate the > >>>>>>>>> 1.x > >>>>>>>>>>>>>>> components > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> remove > >>>>>>>>>>>>>>>>>>>>>>>> them as-is from the 2.x line. Then > >>>>>>>> re-introduce > >>>>>>>>>>>> them > >>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>> record > >>>>>>>>>>>>>>>>>>>>> only > >>>>>>>>>>>>>>>>>>>>>>>> interfaces and built against the > >>> latest > >>>>>> stable > >>>>>>>>>>>>>>>>>>>>>>> Cassandra/Datastax/ScyllaDB > >>>>>>>>>>>>>>>>>>>>>>>> interfaces. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I'd love to hear thoughts from > >> those > >>>>>> closer to > >>>>>>>>>> this > >>>>>>>>>>>>> space > >>>>>>>>>>>>>>>> both > >>>>>>>>>>>>>>>>>> as > >>>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>>>> user > >>>>>>>>>>>>>>>>>>>>>>>> and developer so we can make good > >>> next > >>>>>> steps. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>>> > >>> > >> >