I have assigned the JIRA ticket to myself and added a comment. Does the
status need to be updated?
Let me know if we should have issued the PR against a release branch
instead of trunk.
-Danny
On Tue, Jan 21, 2025 at 1:41 PM Dinesh Joshi wrote:
> Hi Danny,
>
> Thanks for pinging this ist. It w
There are essentially three possible timelines to choose from here: 1) We agree in the next few days to merge to trunk. We will then prioritise rebasing onto trunk and resolving any pre-merge items starting next week.2) There’s some more debate and agreement to merge to trunk in a week or two. In t
A couple questions:
- are there some graphs or raw data that has or could be shared to help
quantify what is meant by “SLOW”? If not maybe worth taking Jon up on his
offer of an ECL build after a last rebase and a short time box? I could
likely take it for a spin over the weekend. Might need a coup
> I don’t find it terrible that the feature is proven out in an internal
> feature branch first if the end result is a better feature for the community.
I don’t think it’s going to be merged and designated as production ready. I
think the intention is to mark it experimental/alpha/beta/whatever
Having played with the branch and confirmed it’s relatively isolated, I would love to see it mergedOn Mar 6, 2025, at 8:44 PM, Benedict Elliott Smith wrote:Because we want to validate against the latest code in trunk, else we are validating stale behaviours. The cost of rebasing is high, so we do
Regarding the merge: I have the same question as Jon about rebasing the
feature branch vs a merge to trunk. And again want to recognize that we are
asking more from the maintainers here. I totally acknowledge this is not
zero cost. But I don’t find it terrible that the feature is proven out in
an i
Hi all,
I would like to make applications using Cassandra Java Driver,
particularly those built with Spring Boot, Quarkus or similar
frameworks, work with OpenJDK CRaC project [1]. I've already created a
patch for Spring Boot [2] but Spring folks think that these changes are
too dependent on
On 3/6/2025 7:16 AM, Jon Haddad wrote:
Assuming everything else is identical, might not matter for S3.
However, not every object store has a filesystem mount.
Regarding sprawling dependencies, we can always make the provider
specific libraries available as a separate download and put them on
Hmm... I took a look at the cep-15-accord branch in GitHub, it looks like
it's several hundred commits behind trunk. Since you'll need to rebase
again before merge *anyways*, would it make sense to do it once more, and I
can publish easy-cass-lab with the latest branch? If folks have concerns,
it
I have no stake in this feature besides thinking it would enable some great
new end user workloads. Also it actually makes my professional life easier
the longer this code is not merged.
But given the new feature (and its caveats) are behind a yaml flag, as well
as opt in at the table level, I don
> I've gotten the impression that there's not a lot of enthusiasm for breaking
> apart the main Cassandra module, but I have wondered if it'd be worth making
> an exception for the interfaces plugins are supposed to code against
Oh, there's *plenty* of enthusiasm. There's been a shortage of conse
This has been on my mind for a while, and I think it's a great idea.
Someone shouldn't need all the C* internals just to implement an interface.
On Thu, Mar 6, 2025 at 1:08 PM Joel Shepherd wrote:
> Splitting this out from the CEP-36 thread.
>
> I agree: dependency collisions at run-time are a p
Splitting this out from the CEP-36 thread.
I agree: dependency collisions at run-time are a problem. It's made even
worse by the possibility of users using multiple plugins (authn, authz,
compression, storage, etc.).
It also cuts two ways. E.g. the interfaces that plugin authenticators
need
The work and effort in accord has been amazing. And I’m sure it sets a new
standard for code quality and correctness testing which I’m also entirely
behind. I also trust the folks working on it want to take it to the a fully
production ready solution. But I’m worried about circumstances out of our
Hey Joel, thanks for chiming in!
Regarding dependencies - while it's possible to provide pluggable
interfaces, the issue I'm concerned about is conflicting versions of
transitive dependencies at runtime. For example, I used a java agent that
had a different version of snakeyaml, and it ended up b
Thanks Scott - That gives me a clear to direction to go in -- Joel.
On 3/5/2025 9:01 PM, C. Scott Andreas wrote:
Joel, thanks for reaching out.
This sounds interesting, I bet there are many who would benefit from
IAM-based authentication.
If you haven't yet, could you request a Jira account
It anyway seems reasonable to me that we would support multiple FileSystemProvider. So perhaps this is really two problems we’re maybe conflating: 1) a mechanism for dropping jars that can register a FileSystemProvider for Cassandra to utilise2) a way to mark directories (from any provider) as “rem
Assuming everything else is identical, might not matter for S3. However,
not every object store has a filesystem mount.
Regarding sprawling dependencies, we can always make the provider specific
libraries available as a separate download and put them on their own thread
with a separate class path.
Hi Michael,
I created https://issues.apache.org/jira/browse/CASSANDRA-20406 to get
this changed.
Kind Regards,
Brandon
On Tue, Mar 4, 2025 at 5:34 AM Michael Roosz wrote:
>
> Hello Cassandra developers,
>
> since the official Cassandra php client driver list currently only contains
> outdated
I think another way of saying what Stefan may be getting at is: what does a library give us that an appropriately configured mount dir doesn’t?We don’t want to treat S3 the same as local disk, but this can be achieved easily with config. Is there some other benefit of direct integration? Well defin
20 matches
Mail list logo
