4.0 Max TTL

[Benedict Elliott Smith <be...@apache.org>]

1.    During ApacheCon, Laxmikant approached me to discuss CASSANDRA-14227.  It was also raised on the list back in January.

 

Taking a closer look, it probably is not very difficult for us to fix this – either by treating the int as unsigned, or by widening it to a long value.  Since this can only easily be done once per major version, and the number of representable dates is steadily declining, there’s a strong case to be made for delivering this for 4.0-beta.

 

The least invasive change is probably to simply permit negative values, and to treat them as unsigned.  However, this or using long would both be modest changes.

 

Does anyone have any strong thoughts or opinions on this?

Re: 4.0 Max TTL

[Paulo Motta <pa...@gmail.com>]

I personally think we should move this forward for the reasons mentioned
beforehand. Widening to a long value seems to be the most pragmatic
approach if we want to get this in for 4.0. Alternatively, we can let
operators choose the precision int vs long in case TTLs are not used.

I'd be happy to assist with a secondary/tertiary review if anyone is
willing to take CASSANDRA-14227.

Em ter, 17 de set de 2019 às 11:50, Sumanth Pasupuleti <
sumanth.pasupuleti.is@gmail.com> escreveu:

> We will have to deal with fixing this TTL issue eventually as more users
> start to deal with the boundaries of currently allowed TTL (which keeps
> declining). It will be neat if we can get this into 4.0 before it is
> released - be it in beta or future 4.0 alpha(s) - the sooner the better, as
> everyone in the community gets busy validating 4.0 bits.
>
> Thanks,
> Sumanth
>
> On Tue, Sep 17, 2019 at 7:33 AM Benedict Elliott Smith <
> benedict@apache.org>
> wrote:
>
> > 1.    During ApacheCon, Laxmikant approached me to discuss
> > CASSANDRA-14227.  It was also raised on the list back in January.
> >
> >
> >
> > Taking a closer look, it probably is not very difficult for us to fix
> this
> > – either by treating the int as unsigned, or by widening it to a long
> > value.  Since this can only easily be done once per major version, and
> the
> > number of representable dates is steadily declining, there’s a strong
> case
> > to be made for delivering this for 4.0-beta.
> >
> >
> >
> > The least invasive change is probably to simply permit negative values,
> > and to treat them as unsigned.  However, this or using long would both be
> > modest changes.
> >
> >
> >
> > Does anyone have any strong thoughts or opinions on this?
> >
> >
>

Re: 4.0 Max TTL

[Sumanth Pasupuleti <su...@gmail.com>]

We will have to deal with fixing this TTL issue eventually as more users
start to deal with the boundaries of currently allowed TTL (which keeps
declining). It will be neat if we can get this into 4.0 before it is
released - be it in beta or future 4.0 alpha(s) - the sooner the better, as
everyone in the community gets busy validating 4.0 bits.

Thanks,
Sumanth

On Tue, Sep 17, 2019 at 7:33 AM Benedict Elliott Smith <be...@apache.org>
wrote:

> 1.    During ApacheCon, Laxmikant approached me to discuss
> CASSANDRA-14227.  It was also raised on the list back in January.
>
>
>
> Taking a closer look, it probably is not very difficult for us to fix this
> – either by treating the int as unsigned, or by widening it to a long
> value.  Since this can only easily be done once per major version, and the
> number of representable dates is steadily declining, there’s a strong case
> to be made for delivering this for 4.0-beta.
>
>
>
> The least invasive change is probably to simply permit negative values,
> and to treat them as unsigned.  However, this or using long would both be
> modest changes.
>
>
>
> Does anyone have any strong thoughts or opinions on this?
>
>