If this is only the default in 5.1/6.0/current trunk, so be it, but the minimum
thing I’d want to build consensus around is no longer allowing empty values in
filtering/index queries for numeric types. (This applies to actual empty values
in filtering expressions, but also things like not matchi
That is the biggest “gotcha” of using the empty value for an int. As soon as
you try to use it as an int and not a byte array, all the drivers convert that
to a null pointer. If you just “SELECT v0” and then get its value from the
result set as a byte array, you get empty bytes, not null. It is
With four +1 votes (3 binding) and zero -1 votes the vote passes.
Thanks all!
On Tue, Feb 11, 2025 at 8:02 AM Josh McKenzie wrote:
> +1
>
> On Mon, Feb 10, 2025, at 6:34 PM, Nate McCall wrote:
>
> +1
> Verified sigs and artifact coordinates.
>
> On Tue, Feb 11, 2025 at 12:30 PM Brandon Williams
My planet was destroyed to make way for hyperspatial express route before I
could get the answer, sorry… anyone interested in getting lunch at the end of
the universe?
> On Feb 11, 2025, at 2:03 PM, Paulo Motta wrote:
>
> On Tue, Feb 11, 2025 at 5:00 PM Patrick McFadin wrote:
>>
>> You get m
On Tue, Feb 11, 2025 at 5:00 PM Patrick McFadin wrote:
>
> You get my vote for the best subject line I've seen this week.
>
+1, I'm deeply saddened that despite this title this post does not
contain the answer to the ultimate question of life, the universe, and
everything. :-(
> On Tue, Feb 11,
You get my vote for the best subject line I've seen this week.
On Tue, Feb 11, 2025 at 1:20 PM Benedict wrote:
>
> Perhaps we should reify this in the type system? Introduce a MAYBE EMPTY
> modifier for column types, or simply name them eg [int] vs int?
>
> I think the problem is today it’s all
Perhaps we should reify this in the type system? Introduce a MAYBE EMPTY modifier for column types, or simply name them eg [int] vs int?I think the problem is today it’s all implicit and - as David says - inconsistent. It would be nice to move away from this as the default for a variety of reasons,
Thanks for the reply!
> AFAIK this EMPTY stuff goes back to thrift days.
This is what I was told, but the expected semantics are not clear so my goal is
to help flesh things out.
> We let people insert these zero length values back then, so we have to
> support those zero length values existin
AFAIK this EMPTY stuff goes back to thrift days. We let people insert
these zero length values back then, so we have to support those zero length
values existing for ever :/.
How useful is such a distinction? I don’t know. Is anybody actually doing
this? Well Andres brought up
https://issues.
The case where allowsEmpty == true AND is meaningless == true is especially
confusing. If I could design this from scratch, I would reject writes and
filtering on EMPTY values for int and the other types where meaningless ==
true. (In other words, if we allow EMPTY, it is meaningful and queryable.
Bringing this discussion to dev@ rather than Slack as we try to figure out
CASSANDRA-20313 and CASSANDRA-19461.
In the type system, we have 2 different (but related) methods:
AbstractType#allowsEmpty- if the user gives empty bytes
(new byte[0]) will the type reject it
Ab
Severity: moderate
Affected versions:
- Apache Cassandra 4.0.16
Description:
Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An
user with MODIFY permission ON ALL KEYSPACES can escalate privileges to
superuser within a targeted Cassandra cluster via unsafe actions to
Welcome to the first OpenJDK Quality Outreach update of 2025!
The first Release Candidate builds of JDK 24 are now available [1] and tt this
stage, only P1 issues will be evaluated. With the JDK 24 General Availability
set for March 18th, the attention is now turning to JDK 25.
JDK 24 will offi
+1
On Mon, Feb 10, 2025, at 6:34 PM, Nate McCall wrote:
> +1
> Verified sigs and artifact coordinates.
>
> On Tue, Feb 11, 2025 at 12:30 PM Brandon Williams wrote:
>> +1
>>
>> Checked sha/sig, maven artifacts, built on j8.
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Feb 6, 2025 at 4:34 PM Br
+1 to putting it in 5.0
On Tue, Feb 11, 2025 at 2:10 AM Mick Semb Wever wrote:
> Any objections to making the following changes also to 5.0 ?
>
> CASSANDRA-20296 proposes the following changes:
>
> 1. G1 to by default use `-XX:G1NewSizePercent=50` to floor the young
> generation's size to 50% o
Any objections to making the following changes also to 5.0 ?
CASSANDRA-20296 proposes the following changes:
1. G1 to by default use `-XX:G1NewSizePercent=50` to floor the young
generation's size to 50% of the heap. (We know in production this can
often be raised to 66% for optimal performance.)
I think it may be better to use LOOSE_NOT_NULL instead of NOT_NULL.
The reason is: NOT_NULL can easily make users think that it is a related
function of MYSQL, but in fact we are different.
Changing a different name may avoid users' preconceived feelings.
Dinesh Joshi 于2025年2月11日周二 01:55写道：
> On
17 matches
Mail list logo
