There will be a LOT of content around using SAI in 5.0.
CCing marketing ML
On Wed, May 10, 2023 at 8:38 PM Jeff Jirsa wrote:
> Changes like this always scare me, but the benefits probably outweigh the
> risks. Probably obviously to whoever implements but please make sure if
> this happens is
Changes like this always scare me, but the benefits probably outweigh the
risks. Probably obviously to whoever implements but please make sure if
this happens is super visible in both NEWS and simultaneously updates the
to-string / to-cql representation of the schema in cqlsh / drivers /
snapshots
Having pulled a lot of developers out of the 2i fire, I would love it if
defaults got a bit more sane. Adding USING...WITH... on CREATE INDEX
seems like the right move for most developers that don't read docs and
assume behavior.
As much as I hate that 2i would be the configured default, I get
+1
> On May 10, 2023, at 9:36 AM, Francisco Guerrero wrote:
>
> +1 (nb)
>
> On 2023/05/10 14:10:06 Jeremiah D Jordan wrote:
>> +1 nb
>>
>>> On May 8, 2023, at 3:52 AM, Piotr Kołaczkowski
>>> wrote:
>>>
>>> Let's vote.
>>>
>>>
+1 (nb)
On 2023/05/10 14:10:06 Jeremiah D Jordan wrote:
> +1 nb
>
> > On May 8, 2023, at 3:52 AM, Piotr Kołaczkowski
> > wrote:
> >
> > Let's vote.
> >
> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
> >
> > Piotr Kołaczkowski
> > e.
> Having to revert to CREATE CUSTOM INDEX sounds pretty awful, so I'd prefer
> allowing USING...WITH... for CREATE INDEX
I have 0 issues with a new syntax to make this more clear
> just deprecating CREATE CUSTOM INDEX (at least after 5.0), but that's more or
> less what my original proposal
tl;dr If you take my original proposal and change only the fact that CREATE
INDEX retains a configurable default, I think we get to the same place?
(Then it's just a matter of what we do in 5.0 vs. after 5.0...)
On Wed, May 10, 2023 at 11:00 AM Caleb Rackliffe
wrote:
> I see a broad desire
> We could introduce new syntax that properly appreciates there’s no
default index, perhaps CREATE LOCAL [type] INDEX? To also make clear that
these indexes involve a partition key or scatter gather
I think this is something we should handle in guardrails space on the query
side for all indexes.
I see a broad desire here to have a configurable (YAML) default
implementation for CREATE INDEX. I'm not strongly opposed to that, as the
concept of a default index implementation is pretty standard for most DBMS
(see Postgres, etc.). However, keep in mind that if we do that, we still
need to
+1 nb
> On May 8, 2023, at 3:52 AM, Piotr Kołaczkowski wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
+1
Kind Regards,
Brandon
On Tue, May 9, 2023 at 12:04 PM Piotr Kołaczkowski
wrote:
>
> Let's vote.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
>
> Piotr Kołaczkowski
> e. pkola...@datastax.com
> w. www.datastax.com
+1
On Wed, 10 May 2023 at 0:40, Dinesh Joshi wrote:
> +1
>
> > On May 8, 2023, at 1:52 AM, Piotr Kołaczkowski
> wrote:
> >
> > Let's vote.
> >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator
> >
> > Piotr Kołaczkowski
> > e. pkola...@datastax.com
> > w.
I’m not convinced by the changing defaults argument here. The characteristics of the two index types are very different, and users with scripts that make indexes today shouldn’t have their behaviour change.We could introduce new syntax that properly appreciates there’s no default index, perhaps
13 matches
Mail list logo
