Hi Jyothsna,
Thank you for this proposal.
While reading it, various questions / points came to my mind:
1) In your examples, Description can take an argument - a comment
describing an element of a schema. However, I can imagine that not all
annotations need to have an argument like that. E.g. @PII can be without
any. It would be nice if your "framework" supported annotation creation
which does not take any arguments. How do you differentiate, on creation,
if an annotation is meant to take an argument or not? All annotations might
take a comment by default, but if a user does not specify any, this would
be also reflected in "DESCRIBE" which would display just the short version
- "@PII" instead of "@PII('')".
2) It seems to me that after CEP-42, we opened doors to the "additions" to
columns. If we have this:
CREATE TABLE ks.tb2 (id int CHECK id > 0 PRIMARY KEY);
or
CREATE TABLE ks.tb3 (id int CHECK id > 0 PRIMARY KEY, col2 text NOT NULL);
I think it would be worth thinking about how to specify annotations with
it. There are already some minor caveats when checks are being mixed with
data masks and I can see how incorporating annotations into this might be a
source of problems which would need to be addressed as well.
Do you propose something like this? I am open-minded about other approaches
here.
CREATE TABLE ks.tb3 (
id int PRIMARY KEY,
col2 text NOT NULL WITH @PII
);
CREATE TABLE ks.tb3 (
id int PRIMARY KEY,
col2 id CHECK col2 > 0 WITH @PII
);
All I am saying is that this integration needs to be thought through to
play together with masks, constraints etc and I think it will not be
completely trivial to do this on syntax level in antlr.
To make your life easier I guess that this would be more appropriate on
grammar level:
CREATE TABLE ks.tb3 (
id int PRIMARY KEY,
col2 id CHECK col2 > 0 ANNOTATIONS @PII AND @Description('123')
);
Also, I am not sure if you already have some prototype or not, but I am
curious how you achieved this:
// Viewing annotations of a table
DESC table <keyspace>.<table>
-- prints
CREATE TABLE <keyspace>.<table> (
column1 text, .....)
WITH @Description('New annotation on table')
because, for now, everything in "WITH" is a completely separate entry in
TableParams.
I guess it might be expanded to something like this to be more illustrative:
CREATE TABLE <keyspace>.<table> (
column1 text, .....)
) WITH additional_write_policy = '99p'
AND allow_auto_snapshot = true
AND bloom_filter_fp_chance = 0.01
...
AND @Description('New annotation on table')
AND @PII
Again, I think that having a dedicated ANNOTATIONS entry
CREATE TABLE <keyspace>.<table> (
column1 text, .....)
) WITH additional_write_policy = '99p'
AND allow_auto_snapshot = true
AND bloom_filter_fp_chance = 0.01
...
AND ANNOTATIONS @PII AND @Description('New annotation on table');
Would be better because then ANNOTATIONS would serve as a "container" for
all of it which would be eventually stored in TCM etc.
On Thu, Aug 7, 2025 at 3:59 AM Jyothsna Konisa <jyothsna1...@gmail.com>
wrote:
> Sorry for the incorrect editable link, here is the updated link to the CEP
> 52: Schema Annotations for ApacheCassandra
> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP+52%3A+Schema+Annotations+for+ApacheCassandra>
>
> On Wed, Aug 6, 2025 at 4:26 PM Jyothsna Konisa <jyothsna1...@gmail.com>
> wrote:
>
>> Hello Everyone!
>>
>> We would like to propose CEP 52: Schema Annotations for ApacheCassandra
>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=373887528&draftShareId=339b7f4e-9bc2-45bd-9a80-b0d4215e3f45&;>
>>
>> This CEP outlines a plan to introduce *Schema Annotations* as a way to
>> add better context to schema elements. We're also proposing a set of new
>> DDL statements to manage these annotations.
>>
>> We believe these annotations will be highly beneficial for several key
>> areas:
>>
>> -
>>
>> GenAI Applications: Providing more context to LLMs could
>> significantly improve the accuracy and relevance of generated content.
>> -
>>
>> Data Governance: Annotations can help in enforcing policies using
>> annotations
>> -
>>
>> Compliance: They can be used to track and manage compliance
>> requirements directly within the schema.
>>
>> We're eager to hear your thoughts and feedback on this proposal. Please
>> keep the discussion within this mailing thread.
>>
>> Thanks for your time and feedback in advance.
>>
>> Best regards,
>>
>> Jyothsna & Yifan
>>
>>
>>
>>
