Sorry I didn’t see on my phone this has already been brought up.
On Fri, Feb 14, 2025, at 9:17 PM, Ariel Weisberg wrote:
> Hi,
>
> This is already specified in SQL. Columns that aren’t nullable need
> either to have a default value or a value specified in each
> insert/update.
>
> Unless I am wr
Hi,
This is already specified in SQL. Columns that aren’t nullable need either to
have a default value or a value specified in each insert/update.
Unless I am wrong about the standard or there is a persuasive reason to deviate
from the standard I would argue this is actually a bug.
A persuasiv
Guo: From your name change suggestion, I think I’d be -1 on that. In my head,
LOOSE_NOT_NULL would imply that there is another NOT_NULL which happens to be
NOT_NULL. Not the case now after this thread discussion. There are a lot of
differences between MYSQL and Cassandra, and this constraint beh
Enough time has passed without anybody else stepping in so I think it is
reasonable to go with behaviour of STRICTLY_NOT_NULL renamed as NOT_NULL
and dropping the "weak" NOT_NULL as described in the original e-mail.
On Tue, Feb 11, 2025 at 9:44 AM guo Maxwell wrote:
> I think it may be better to
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
On Mon, Feb 10, 2025 at 9:05 AM Bernardo Botella <
conta...@bernardobotella.com> wrote:
> We have consensus then. Let’s ditch the non strict version, and rename the
> STRICTLY_NOT_NULL to NOT_NULL.
>
Can you give this thread at least 24-48 hours to ensure we capture any
other perspectives?
strict
>> version.
>> How about we just drop the LOOSE one and call the STRICT one “NOT_NULL”?
>>
>> - Yifan
>> From: Bernardo Botella > <mailto:conta...@bernardobotella.com>>
>> Sent: Monday, February 10, 2025 8:44:13 AM
>> To: dev@cassan
gt; How about we just drop the LOOSE one and call the STRICT one “NOT_NULL”?
>
> - Yifan
> --
> *From:* Bernardo Botella
> *Sent:* Monday, February 10, 2025 8:44:13 AM
> *To:* dev@cassandra.apache.org
> *Subject:* Re: [DISCUSS] NOT_NULL constraint vs S
Subject: Re: [DISCUSS] NOT_NULL constraint vs STRICTLY_NOT_NULL constraint
To recap,
The sentiment I am getting is that NOT_NULL allowing null values is too
confusing. Nice, that’s why we started the thread.
As an alternative, instead of ditching the loose not null constraint, I propose
we
To recap,
The sentiment I am getting is that NOT_NULL allowing null values is too
confusing. Nice, that’s why we started the thread.
As an alternative, instead of ditching the loose not null constraint, I propose
we change the “default” behavior. From my initial proposal, I suggest renaming
th
On Mon, Feb 10, 2025 at 5:20 PM Dinesh Joshi wrote:
> In my head NOT_NULL constraint implies that the column must be specified
> on each write and must not be NULL. If a column with the NOT_NULL
> constraint is omitted during a write then shouldn’t it be treated as if it
> was specified and set t
Rereading this:
I do think any implementation of NOT NULL that has a way to let NULL in is
bad. So I would be -1 on the proposal here that lets through INSERTs that
don’t specify the column
and also: " requiring that for INSERT, letting UPDATE be “user beware” -
and you -1 it as well, that looks
In my head NOT_NULL constraint implies that the column must be specified on
each write and must not be NULL. If a column with the NOT_NULL constraint
is omitted during a write then shouldn’t it be treated as if it was
specified and set to NULL?
If the column has a non-NULL value that was previousl
That looks like our STRICT_NOT_NULL would be "NOT NULL", so we would
collapse the second, stricter, case into the default one, if I understand
correctly.
Would you mind telling us what you would actually +1? You have -1 both 1)
and 2).
On Mon, Feb 10, 2025 at 5:00 PM Jeremiah Jordan
wrote:
> Ha
Having thought about this in the past, some options that have come up in
those discussions were:
1. Constraints forcing users to always specify a value for a given
column or all columns. Only allow NOT NULL for columns with such a
constraint applied.
2. Similar to the above but only
The reason it looks "strange" is that we are dealing with a completely
different concept of "NOT NULL" from e.g. MySQL.
In MySQL (as I just tried here locally so I describe what I saw), a user
has to, by default, specify all columns in the table for an insert. There
is, by default, nothing like wh
I will create a Jira to keep track of that “NO VERIFY” suggestion. For this
thread, I’d like to stick to the actual proposal for both NOT_NULL and
STRICTLY_NOT_NULL constraints Stefan and I are adding on the patch.
> On Feb 10, 2025, at 7:18 AM, Benedict wrote:
>
> Thanks. While I agree we sh
Thanks. While I agree we shouldn’t be applying these constraints post hoc on read or compaction, I think we need to make clear to the user whether we are validating a new constraint before accepting it for alter table. Which is to say I think alter table should require something like “NO VERIFY” or
Hi. These was a topic we discussed during the ML thread:
https://lists.apache.org/thread/xc2phmxgsc7t3y9b23079vbflrhyyywj
Here was one of my answers on that:
https://lists.apache.org/thread/76olqf6225noygxcclsrs56ngnlmcvxv
It was also specified in the CEP
(https://cwiki.apache.org/confluence/d
This is counterintuitive to me. The constraint should be applied to the table,
not to the update. NOT NULL should imply a value is always specified.
How are you handling this for tables that already exist? Can we alter table to
add constraints, and if so what are the semantics?
> On 10 Feb 2025
Hi everyone,
Stefan Miklosovic and I have been working on a NOT_NULL
(https://github.com/apache/cassandra/pull/3867) constraint to be added to the
constraints tool belt, and a really interesting conversation came up.
First, as a problem statement, let's consider this:
-
21 matches
Mail list logo
