Can we have a page or a JIRA label which users can see to know why it is
experimental. Putting a warning without telling why is not good. But since
warning is better than nothing, I am -0 on warn
> On Jan 26, 2019, at 9:37 AM, Andrés de la Peña
> wrote:
>
> I agree with Paulo's proposal. I th
I agree with Paulo's proposal. I think it will give us a very desirable
homogeneity in how we deal with experimental features.
I'm +1 to warning, config property, and experimental features (SASI and MV)
disabled by default in trunk.
These are the explicit votes for now, if I'm counting right:
-
+1 to enable_sasi_indexes flag
+1 to disabling experimental features by default on 4.0 (SASI and MVs,
transient replication already disabled)
Regarding the warning on creation of SASI indexes, I think that's a
user-level warning complimentary to the flag, which is targeted to admins,
so +1. If peo
If we want to put a warning, we should list in a doc all the open issues it
has along with explanation of how it can impact. We have a few in the first
email of this thread but we should put it in a doc for people to know what
are the issues and if they want to take that risk.
On Wed, Jan 16, 20
Which, if I'm not mistaken, is the goal here?
On Wed, Jan 16, 2019 at 5:12 PM Jeff Jirsa wrote:
> The cost is in how many users you scare away
>
> --
> Jeff Jirsa
>
>
> > On Jan 16, 2019, at 2:34 PM, Brandon Williams wrote:
> >
> > Also it costs us nothing to add it.
> >
> >> On Wed, Jan 16, 20
The cost is in how many users you scare away
--
Jeff Jirsa
> On Jan 16, 2019, at 2:34 PM, Brandon Williams wrote:
>
> Also it costs us nothing to add it.
>
>> On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad wrote:
>>
>> I'm +1 on the warning for two reasons.
>>
>>> A cqlsh warning only a
Also it costs us nothing to add it.
On Wed, Jan 16, 2019 at 4:29 PM Jonathan Haddad wrote:
> I'm +1 on the warning for two reasons.
>
> > A cqlsh warning only applies to those that create the sasi via cqlsh.
>
> 1. When people are creating their schemas in development, this is usually
> the firs
I'm +1 on the warning for two reasons.
> A cqlsh warning only applies to those that create the sasi via cqlsh.
1. When people are creating their schemas in development, this is usually
the first step. You use the REPL to figure out what you need, then you
copy your schema somewhere else. The wa
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT?
I'm -0 on this.
A single line warning in the logs on the sasi creation won't be noticed by many
users.
A cqlsh warning only app
Thanks for the feedback.
It seems we agree to the config property, disabled by default in trunk.
Regarding the warning, we might add it at least in 3.11, since for that
version the property to enable SASI is going to be present but not disabled
by default. WDYT?
On Tue, 15 Jan 2019 at 11:24, Benja
+1 on config. +1 on disabling by default
On Tue, Jan 15, 2019 at 6:51 AM Jeff Jirsa wrote:
> +1 on config
> -0 on warning
> -0 on disabling by default
>
>
> --
> Jeff Jirsa
>
>
> > On Jan 14, 2019, at 9:22 PM, Taylor Cressy
> wrote:
> >
> > +1 on config. +1 on disabling.
> >
> > +1 on applying
+1 on config
-0 on warning
-0 on disabling by default
--
Jeff Jirsa
> On Jan 14, 2019, at 9:22 PM, Taylor Cressy wrote:
>
> +1 on config. +1 on disabling.
>
> +1 on applying it to materialized views as well.
>
>> On Jan 14, 2019, at 17:29, Joshua McKenzie wrote:
>>
>> +1 on config cha
+1 on yaml config. +1 on disable by default.
On Tue, 15 Jan 2019 at 13:23 Taylor Cressy wrote:
> +1 on config. +1 on disabling.
>
> +1 on applying it to materialized views as well.
>
> > On Jan 14, 2019, at 17:29, Joshua McKenzie wrote:
> >
> > +1 on config change, +1 on disabling, and so long
+1 on config. +1 on disabling.
+1 on applying it to materialized views as well.
> On Jan 14, 2019, at 17:29, Joshua McKenzie wrote:
>
> +1 on config change, +1 on disabling, and so long as the comments make the
> limitations and risks extremely clear, I'm fine w/out the client warning.
>
> O
+1 on config change, +1 on disabling, and so long as the comments make the
limitations and risks extremely clear, I'm fine w/out the client warning.
On Mon, Jan 14, 2019 at 12:28 PM Andrés de la Peña
wrote:
> I mean disabling the creation of new SASI indices with CREATE INDEX
> statement, the ex
I mean disabling the creation of new SASI indices with CREATE INDEX
statement, the existing indexes would continue working. The CQL client
warning will be thrown with that creation statement as well (if they are
enabled).
On Mon, 14 Jan 2019 at 20:18, Jeff Jirsa wrote:
> When we say disable, do
When we say disable, do you mean disable creation of new SASI indices, or
disable using existing ones? I assume it's just creation of new?
On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña
wrote:
> Hello all,
>
> It is my understanding that SASI is still to be considered an
> experimental/beta
I amend to +1 everything except warning, which I'm +0 on.
On Mon, Jan 14, 2019 at 1:59 PM Caleb Rackliffe
wrote:
> +1 to config and disable
>
> On Mon, Jan 14, 2019, 1:54 PM Mick Semb Wever
> >
> >
> > > The purpose for this thread is discussing whether we want to add this
> > > warning, the co
+1 to config and disable
On Mon, Jan 14, 2019, 1:54 PM Mick Semb Wever
>
> > The purpose for this thread is discussing whether we want to add this
> > warning, the config property and, more controversially, if we want to set
> > SASI as disabled by default in trunk.
>
>
> I'm +1 on everything, ex
> The purpose for this thread is discussing whether we want to add this
> warning, the config property and, more controversially, if we want to set
> SASI as disabled by default in trunk.
I'm +1 on everything, except the warning.
I think if we add the config property and it's disabled in trun
+1 to warn, config, and disable.
On Mon, Jan 14, 2019 at 1:45 PM Jonathan Haddad wrote:
> I'm very much in favor of a warning, and I lean towards disabling them (and
> MVs, while we're at it) by default as well.
>
> I've seen both features be the death of clusters, and are a major risk for
> tea
I'm very much in favor of a warning, and I lean towards disabling them (and
MVs, while we're at it) by default as well.
I've seen both features be the death of clusters, and are a major risk for
teams that are brand new to Cassandra.
On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña
wrote:
>
Hello all,
It is my understanding that SASI is still to be considered an
experimental/beta feature, and they apparently are not being very actively
developed. Some higlighted problems in SASI are:
- OOMs during flush, as it is described in CASSANDRA-12662
- General secondary index consistency pro
23 matches
Mail list logo
