> Does this imply that each release is allowed to make breaking changes
> (assuming they followed the “correct” deprecation process)? My first
> instinct is to not like this
Does the clarification in the earlier thread help shift your perspective /
address your concerns here David?
Will leave
_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
