+1 I agree with Brandon. It's more like a bug imo.
On 20/9/23 21:42, Caleb Rackliffe wrote:
+1 on a 5.0 backport
On Wed, Sep 20, 2023 at 2:26 PM Brandon Williams wrote:
I think it could be argued that not retrying messages is a bug, I am
+1 on including this in 5.0.
Kind Regards,
+1 for jvector rather than forked lucene classes. On Sep 20, 2023, at 5:14 PM, German Eichberger via dev wrote:
+1
I am biased because DiskANN is from Microsoft Research but it's a good library/algorithm
From: Mike Adamson
Sent: Wednesday, September 20, 2023 8:58 AM
To: dev
Subject
+1
I am biased because DiskANN is from Microsoft Research but it's a good
library/algorithm
From: Mike Adamson
Sent: Wednesday, September 20, 2023 8:58 AM
To: dev
Subject: [EXTERNAL] [DISCUSS] Add JVector as a dependency for CEP-30
You don't often get email fr
+1 on a 5.0 backport
On Wed, Sep 20, 2023 at 2:26 PM Brandon Williams wrote:
> I think it could be argued that not retrying messages is a bug, I am
> +1 on including this in 5.0.
>
> Kind Regards,
> Brandon
>
> On Tue, Sep 19, 2023 at 1:16 PM David Capwell wrote:
> >
> > To try to get repair mo
I think it could be argued that not retrying messages is a bug, I am
+1 on including this in 5.0.
Kind Regards,
Brandon
On Tue, Sep 19, 2023 at 1:16 PM David Capwell wrote:
>
> To try to get repair more stable, I added optional retry logic (patch is
> still in review) to a handful of critical r
> I don’t think we can readily migrate old types away from this however,
> without breaking backwards compatibility.
Given that java driver has a different behavior from server, I wouldn’t be
shocked to see that other drivers also have their own custom behaviors… so not
clear how to migrate un
The original patch for CEP-30 brought several modified Lucene classes
in-tree to implement the concurrent HNSW graph used by the vector index.
These classes are now being replaced with the io.github.jbellis.jvector
library, which contains an improved diskANN implementation for the on-disk
graph fo
> So, not for new types.
> Should we make the Vector type non-emptiable and stick to it for the new
> types?
Yep, works for me.
We should also update the test
org.apache.cassandra.db.marshal.AbstractTypeTest#empty to detect this for new
types by making org.apache.cassandra.db.marshal.Abstract
Allowing zero-length byte arrays for most old types is just a legacy from
Darker Days. It’s a distinct concern from columns being nullable or not.
There are a couple types where this makes sense: strings and blobs. All else
should not allow this except for backward compatibility reasons. So, not
Yes, if this is what was meant by empty I agree. It’s nonsensical for most
types. Apologies for any confusion.
I don’t think we can readily migrate old types away from this however, without
breaking backwards compatibility. We can only prevent its use in the CQL layer
where support isn’t requir
10 matches
Mail list logo
