> When does empty mean null?
Most types are this way
@Test
public void nullExample()
{
createTable("CREATE TABLE %s (pk int primary key, cuteness int)");
execute("INSERT INTO %s (pk, cuteness) VALUES (0, ?)", ByteBuffer.wrap(new
byte[0]));
Row result = execute("SELECT * FROM %s WHERE pk=0").one
When does empty mean null? My understanding was that empty is a valid value
for the types that support it, separate from null (aka a tombstone). Do we have
types where writing an empty value creates a tombstone?
I agree with David that my preference would be for only blob and string like
types
I support including this in 5.0.
This looks to me like a significant correctness and stabilization effort, very
similar to other large bodies of work we merged in post freeze for testing and
stabilizing 4.0.
On Tue, Sep 19, 2023, at 5:42 PM, Chris Lohfink wrote:
> I absolutely love the idea of
I absolutely love the idea of this being in 5.0, I am +1 for what it
is worth
On Tue, Sep 19, 2023 at 4:04 PM David Capwell wrote:
> To try to get repair more stable, I added optional retry logic (patch is
> still in review) to a handful of critical repair verbs. This patch is
> disabled by def
To try to get repair more stable, I added optional retry logic (patch is still
in review) to a handful of critical repair verbs. This patch is disabled by
default but allows you to opt-in to retries so ephemeral issues don’t cause a
repair to fail after running for a long time (assuming they re
> When we introduced TINYINT and SMALLINT (CASSANDRA-895) we started making
> types non -emptiable. This approach makes more sense to me as having to deal
> with empty value is error prone in my opinion.
I agree it’s confusing, and in the patch I found that different code paths
didn’t handle th
> I am strongly in favour of permitting the table definition forbidding nulls -
> and perhaps even defaulting to this behaviour. But I don’t think we should
> have types that are inherently incapable of being null.
I'm with Benedict. Seems like this could help prevent whatever "nulls in
primary
If I understand this suggestion correctly it is a whole can of worms, as types
that can never be null prevent us ever supporting outer joins that return these
types.
I am strongly in favour of permitting the table definition forbidding nulls -
and perhaps even defaulting to this behaviour. But
To make sure I understand this right; does that mean there will be a default
value for unset fields? Like 0 for numerical values, and an empty vector (I
presume) for the vector type?
On Fri, Sep 15, 2023, at 11:46 AM, Benjamin Lerer wrote:
> Hi everybody,
>
> I noticed that the new Vector type
