Maybe I misremember the convo, but I thought both of these was possible:
CREATE table test ( id int primary key
val int check val > 0,
val2 int
)
INSERT INTO test (id) values (1); ## inserts with empty val
UPDATE test set val2 = 1; ## inserts with empty val
Are you saying supplying val is req
_A bigger issue, is the actual behavior, in that you can say NOT NULL and
still easily get null values by not supplying the value. The constraint is
more of a weakly applied suggestion._
This is not true. You can not really put there null. See other discussion
about this behaviour on ML.
On Wed,
I thought we had agreed previously that NOT NULL would require that you specify the value?Regarding Accord, great question Jon. I’m in favour of moving towards SQL semantics wherever possible, but I am uncertain how best to do it for features that are already in use. David has spotted some semantic
I think the world is fairly used to NOT NULL in line with the type. I
don't see much value in paving our own path for things that are established
norms. Let's not reinvent wheels that don't need reinventing.
I also think it's fine if the generated CQL from describe doesn't match the
user's input
Maybe I am too naive and idealist but I can see a world where, even we
enable them to do it like "val int not null", after they describe a table
and they see "val int check not null" they start to use the latter form
because they would be tired of switching two forms in their head all the
time when
I may be to blame for some of that energy. :D
No, we don't have consensus on that direction, but I think we will
eventually. CQL started out as a subset of SQL but has drifted because
features get added async and there just hasn't been any formal standard or
road map or lofty goal. We've been layi
> If we have a goal of eventually providing ANSI SQL support one day, we should
> at least stick to the ANSI SQL standard where applicable for features in the
> meantime.
Do we collectively have that goal? Not disagreeing with it at all, genuinely
curious.
Broadly I agree that we should definit
If we have a goal of eventually providing ANSI SQL support one day, we should at least stick to the ANSI SQL standard where applicable for features in the meantime. AFAICT the reason everyone else does this the same is it is part of the standard. So, I am more than happy to stick to the CHECK quali
I am not certain if the ANSI SQL standard requires that any _expression_ be supported, but either way it is much better to implement a strict subset of a feature than to implement an overlapping feature we can never synchronise with the standard.Accord is also capable of imposing multi column expre
One argument I have against using columns in the constraint is that we
currently are not able to actually handle the CHECK spec in SQL. In SQL the
CHECK expression is a valid search expression (eg. price > 42 AND tag = ‘foo’),
and is limited to the current row.
Where we differ in Apache Cassan
Consistency *within* our own ecosystem supersedes consistency with other
familiar ecosystems IMO.
I'd prefer we consistently apply the CHECK keyword and don't have special cases
that omit it, or perhaps have those as optional syntactic sugar but at its base
the syntax is uniform and consistent.
To be honest, I agree with Bernardo here.
The requirement to have "val int not null" makes sense at first, but it is
not so straightforward.
I think that what we are trying to do here is to "copy like they have it"
because ... well, because they have it like that. And we do not want to
differ too
Now this is becoming a really interesting discussion. Thanks everyone for
pitching in!
Here is my take on some of the proposed changes:
We are talking about treating some constraints (NOT_NULL, JSON) as special
cases by omitting the CHECK keyword (not reserved as per current
implementation). N
As Yifan already said, "check" is not a reserved word now and its usage
does not collide with anything.
If people have columns, tables, keyspaces with name "check" that seems to
work already so they don't need to do anything:
CREATE TABLE ks.tb (id int check id > 0, val int check val > 0, primary
On Sun, Apr 13, 2025 at 9:24 AM Patrick McFadin wrote:
> I'm loving all the syntax discussion lately. It's a good debate and
> essential for the project's future with a good developer experience.
>
+1
> On NULL. I've been asked this a million times by end users. Why is there
> no "NOT NULL" in
gt;>
>>>>> On 11 Apr 2025, at 10:57, Štefan Miklošovič
>>>>> wrote:
>>>>>
>>>>>
>>>>> While modelling that, we followed how it is done in SQL world,
>>>>> PostgreSQL as well as MySQL both use CHECK.
>>>
gt;>
>>>> On Fri, Apr 11, 2025 at 10:43 AM Benedict wrote:
>>>>
>>>>> I would prefer require/expect/is over check
>>>>>
>>>>> On 11 Apr 2025, at 08:05, Štefan Miklošovič
>>>>> wrote:
>>>>>
>>&g
dict wrote:
>>>
>>>> I would prefer require/expect/is over check
>>>>
>>>> On 11 Apr 2025, at 08:05, Štefan Miklošovič
>>>> wrote:
>>>>
>>>>
>>>> Yes, you will have it like that :) Thank you for this idea
; I would prefer require/expect/is over check
>>>>
>>>> On 11 Apr 2025, at 08:05, Štefan Miklošovič
>>>> wrote:
>>>>
>>>>
>>>> Yes, you will have it like that :) Thank you for this idea. Great
>>>> exampl
ECK NOT NULL AND JSON AND LENGTH() < 1024
>>>>
>>>> Here is a similar accord CQL
>>>>
>>>> BEGIN TRANSACTION
>>>> LET a = (…);
>>>> IF a IS NOT NULL
>>>> AND a.b IS NOT NULL
>>>> AND a.c IS NULL;
se domains.
>>>
>>> On Fri, Apr 11, 2025 at 12:29 AM David Capwell
>>> wrote:
>>>
>>>> I am biased but I do prefer
>>>>
>>>> val3 text CHECK NOT NULL AND JSON AND LENGTH() < 1024
>>>>
>>>> Here is a similar accord CQL
>>>>
>>
ink it needs to be a reserved keyword with the proposal.
From: C. Scott Andreas <sc...@paradoxica.net>
Sent: Thursday, April 10, 2025 7:59:35 AM
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Cc: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: Co
CQL
>>>
>>> BEGIN TRANSACTION
>>> LET a = (…);
>>> IF a IS NOT NULL
>>> AND a.b IS NOT NULL
>>> AND a.c IS NULL; THEN
>>> — profit
>>> END IF
>>> COMMIT TRANSACTION
>>>
>>> On Apr
t;>>>
>>>>>> On Apr 10, 2025, at 8:46 AM, Yifan Cai >>>>> <mailto:yc25c...@gmail.com>> wrote:
>>>>>>
>>>>>> Re: reserved keywords, “check” is currently not, and I don’t think it
>>>>>> needs to be
April 10, 2025 7:59:35 AM
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Cc: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: Constraint's "not null" alignment with transactions and their simplification
If the proposal does not introduce “check” as a res
on’t think it needs to be a reserved keyword with the proposal.
From: C. Scott Andreas <sc...@paradoxica.net>
Sent: Thursday, April 10, 2025 7:59:35 AM
To: dev@cassandra.apache.org <dev@cassandra.apache.org>
Cc: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subjec
> needs to be a reserved keyword with the proposal.
>>
>> --
>> *From:* C. Scott Andreas
>> *Sent:* Thursday, April 10, 2025 7:59:35 AM
>> *To:* dev@cassandra.apache.org
>> *Cc:* dev@cassandra.apache.org
>> *Subject:* Re: Cons
ndra.apache.org>
Cc: dev@cassandra.apache.org <dev@cassandra.apache.org>
Subject: Re: Constraint's "not null" alignment with transactions and their simplification
If the proposal does not introduce “check” as a reserved keyword that would require quoting in existing DDL/DML, this concern
k” is currently not, and I don’t think it
> needs to be a reserved keyword with the proposal.
>
> --
> *From:* C. Scott Andreas
> *Sent:* Thursday, April 10, 2025 7:59:35 AM
> *To:* dev@cassandra.apache.org
> *Cc:* dev@cassandra.apache.org
&g
ndra.apache.org
> Subject: Re: Constraint's "not null" alignment with transactions and their
> simplification
>
> If the proposal does not introduce “check” as a reserved keyword that would
> require quoting in existing DDL/DML, this concern doesn’t apply and the email
This looks like a really nice improvement to me.
On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič
wrote:
> Recently, David Capwell was commenting on constraints in one of Slack
> threads (1) in dev channel and he suggested that the current form of "not
> null" constraint we have right now in p
: Constraint's "not null" alignment with transactions and their
simplification
If the proposal does not introduce “check” as a reserved keyword that would
require quoting in existing DDL/DML, this concern doesn’t apply and the email
below can be ignored. This might be the case if “CHE
If the proposal does not introduce “check” as a reserved keyword that would require quoting in existing DDL/DML, this concern doesn’t apply and the email below can be ignored. This might be the case if “CHECK NOT NULL” is the full token introduced rather than “CHECK” separately from constraints tha
Recently, David Capwell was commenting on constraints in one of Slack
threads (1) in dev channel and he suggested that the current form of "not
null" constraint we have right now in place, e.g like this
create table ks.tb (id int primary key, val int check not_null(val));
could be instead of that
34 matches
Mail list logo
