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
>

Reply via email to