I have just created CASSANDRA-18876 for this. I'll post a patch very soon.
On Wed, 20 Sept 2023 at 19:41, David Capwell wrote:
> I don’t think we can readily migrate old types away from this however,
> without breaking backwards compatibility.
>
>
> Given that java driver has a different behavio
> I don’t think we can readily migrate old types away from this however,
> without breaking backwards compatibility.
Given that java driver has a different behavior from server, I wouldn’t be
shocked to see that other drivers also have their own custom behaviors… so not
clear how to migrate un
> So, not for new types.
> Should we make the Vector type non-emptiable and stick to it for the new
> types?
Yep, works for me.
We should also update the test
org.apache.cassandra.db.marshal.AbstractTypeTest#empty to detect this for new
types by making org.apache.cassandra.db.marshal.Abstract
Allowing zero-length byte arrays for most old types is just a legacy from
Darker Days. It’s a distinct concern from columns being nullable or not.
There are a couple types where this makes sense: strings and blobs. All else
should not allow this except for backward compatibility reasons. So, not
Yes, if this is what was meant by empty I agree. It’s nonsensical for most
types. Apologies for any confusion.
I don’t think we can readily migrate old types away from this however, without
breaking backwards compatibility. We can only prevent its use in the CQL layer
where support isn’t requir
> 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
> 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
11 matches
Mail list logo
