You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The requirement is excluding any use case where the topic data does not have a copy of the key in the value. It is also confusing users. It is already possible to have tables in the metastore that does not have a key field, consider:
CREATETABLET1 (ID INT, OTHER INT) WITH (KEY='ID', ...);
CREATETABLET2ASSELECT OTHER FROM T1l;
T2 will not have a key field set as the source's key field is not in the projection.
The KEY property should be an optional optimisation hint, that allows KSQL to avoid unnecessary repartitions
The text was updated successfully, but these errors were encountered:
The requirement is excluding any use case where the topic data does not have a copy of the key in the value. It is also confusing users. It is already possible to have tables in the metastore that does not have a key field, consider:
T2
will not have a key field set as the source's key field is not in the projection.The
KEY
property should be an optional optimisation hint, that allows KSQL to avoid unnecessary repartitionsThe text was updated successfully, but these errors were encountered: