Fair enough, Joe.
Matt,
I poked around your branch a little this evening. I agree with you and
David 100% now on the need for some sort of abstraction. I think the Graph
Bundle's model could serve as a good starting point for how to approach the
problem. The client drivers in that bundle do the
Mike,
The bundles we include cannot have libs with know vulns and that last a
very long time. That is a more pressing blocker.
As noted top of thread we all recognize the importance of being able to
integrate with Cassandra but including that must come with active mx
especially as it relates to
The scope tag was probably copy pasta. You raise a valid point about the
processor dependencies that completely slipped my mind. That said, I think
it's premature to remove the cassandra bundle until we have a working
replacement. I would consider that support a blocker for 2.X.
On Fri, Mar 22,
David beat me to it :) IMO the only NAR that should have any dependencies
on Cassandra is the services NAR, not the processors or services API.
On Fri, Mar 22, 2024 at 11:10 AM David Handermann <
exceptionfact...@apache.org> wrote:
> Mike,
>
> Thanks for sharing the branch, it is helpful to have
Mike,
Thanks for sharing the branch, it is helpful to have that as a
reference example. Have you been able to exercise any of that approach
at runtime?
Based on what is there right now, attempting to mark the DataStax
java-driver-core as provided does not look like it will work. It may
pass unit
Work so far: https://github.com/MikeThomsen/nifi/tree/cql-changes
On Thu, Mar 21, 2024 at 9:52 AM Mike Thomsen wrote:
> Matt/David,
>
> By this evening, I should be at a point where I can share my branch. It
> should be far enough along that y'all can see what I mean about how most of
> the
