That should never need to happen in UCS as far as I understand. Levels should
be defined by the properties of the sstable, not by assignment, so all sstables
should be placed in the correct bucket on creation by definition. I haven’t
read the code though, so there might be some impediment to tha
I am strongly against early integration, because we can't / don't remove
things when we should. MVs are the prime example here, as is the current
iteration of Vector search.
Early integration works fine when it's internal software that you have
control over, it doesn't work well for software that
On Mon, Dec 9, 2024 at 12:26 PM Jon Haddad wrote:
> I hope I've made my point. The bar for merging in new functionality
> should be higher. Features should work with 1TB of data on 3 nodes, that's
> a low bar. I've spent at least a thousand hours over the last 5 years
> developing the tooling
On Mon, Dec 9, 2024 at 10:52 AM Jeremy Hanna
wrote:
> In the case of UCS, is it in a beta state until we resolve the discussions
> around UX/documentation? From a functional and production usage
> perspective, it has been the only compaction strategy available for users
> in DataStax's Astra man
>
> Totally agree, but even with the excellent tooling you've worked on were
> it universally adopted and Harry + Simulator, we're still not exercising
> hundreds of nodes with petabytes of data heavily using new features in
> surprising ways; I argue that this would be necessary in order to certif
Great! I'll start an email thread with everyone who raised their hands (and
add any others who do later).
On Sun, Dec 8, 2024 at 6:51 AM Aaron wrote:
> Melissa,
>
> I would be happy to help, as well.
>
> Thanks,
>
> Aaron
>
>
> On Fri, Dec 6, 2024 at 11:56 PM Soheil Rahsaz
> wrote:
>
>> Hello
> On Dec 9, 2024, at 10:52 AM, Jeremy Hanna wrote:
>
>
>
> In the case of UCS, is it in a beta state until we resolve the discussions
> around UX/documentation? From a functional and production usage perspective,
> it has been the only compaction strategy available for users in DataStax'
Huh, I didn't notice it when I grepped the code base. I stand corrected.
Jon
On Mon, Dec 9, 2024 at 10:57 AM Ekaterina Dimitrova
wrote:
> Hey Jon,
> The following quick test shows me that vector search is marked as
> experimental (it is just not in cassandra.yaml as materialized views, etc)
>
> However I don't think "beta" is much better. I don't think it should be the
> path for all new features - I think it should be a case-by-case basis. Going
> to the next major/minor version in and of itself obviously doesn't make the
> feature more stable or more production ready. We would n
On 2024/12/09 17:33:09 Benedict wrote:
> I think it would make sense to support overriding the default FP in the UCS
> parameters, so we can treat it as a direct replacement. Desiree FP is
> directly related to sstable overlaps after all.
>
> Can you think of any other usability gaps like t
I think "experimental" isn't very helpful or useful except in the case of MVs.
It's like when we said "unsafe assassinate endpoint" - it pretty much meant -
don't use this unless you know what you're doing. I don't think new features
fall into that category.
As an example, the Java driver doc
Hey Jon,
The following quick test shows me that vector search is marked as
experimental (it is just not in cassandra.yaml as materialized views, etc)
cqlsh:k> CREATE TABLE t (pk int, str_val text, val vector,
PRIMARY KEY(pk));
cqlsh:k> CREATE CUSTOM INDEX ON t(val) USING 'StorageAttachedIndex';
The tough thing here is that MVs are marked experimental retroactively,
because by the time the problems were known, there wasn't much anyone could
do. Experimental was our way of saying "oops, we screwed up, let's put a
label on it" and the same label got applied to a bunch of new stuff
including
I'm a little worried by the idea of grouping in MVs with things like a Java
version under the same "beta" label (acknowledging that they are currently
grouped under the same "experimental" label).
To me, "beta" implies it's pretty close to production ready and there is an
intention to get it to
I like this. There's a few things marked as experimental today, so I'll
take a stab at making this more concrete, and I think we should be open to
graduating certain things out of beta to GA at a faster cycle than a major
release.
Java versions, for example, should really move out of "beta" quick
I think it would make sense to support overriding the default FP in the UCS
parameters, so we can treat it as a direct replacement. Desiree FP is directly
related to sstable overlaps after all.
Can you think of any other usability gaps like this?
> On 9 Dec 2024, at 12:06, Jeff Jirsa wrote:
>
On 2024/12/09 16:26:45 Benedict wrote:
> I think it’s important to remember that UCS broadly speaking subsumes both LCS
> and STCS, with various subtle but important refinements. So while it offers a
> broader parameter space it might be best to conceive of it as a suite of
> compaction strategi
I think it’s important to remember that UCS broadly speaking subsumes both LCS and STCS, with various subtle but important refinements. So while it offers a broader parameter space it might be best to conceive of it as a suite of compaction strategies, two of which are direct replacements to LCS an
Very true I was too harsh when trying to enumerate what I saw as
blockers, and that wasn't fair of me as a lot of great work has gone into
it. I am sorry for that!
> Maybe telling what problem you actually have with it and how to simplify
so it is easier to digest would be more appropriate.
The t
Jon stated:
> Side note: I think experimental has been over-used and has lost all meaning.
> How is Java 17 experimental? Very confusing for the community.
Dinesh followed with:
> Philosophically, as a project, we should wait until critical features like
> these reach a certain level of maturi
It won’t work *properly* with current versions but the tooling should still
handle it gracefully without blowing up. It just won’t generate the full docs.
But arguably we don’t really care about that much - as other have mentioned, C*
javadoc comments are mainly consumed from inside IDEs.
So mi
21 matches
Mail list logo
