My concern about mentioning other potential constraints to be implemented in the future on the CEP is it may derail the conversation from the set of initial ones I want to propose, which are size and value constraints. There is definitely a lot of other potential constraints that we could discuss in future updates. For example:
For numeric types: - Max, Min, equality, difference (included) For date types: - Range (as you mentioned) For text based types: - Size (included) - isJson - complies with a pattern (as you mentioned) - is block listed - complies with an enum General table constraints (including one or more columns): - Compare between numeric types (a < b, a > b, a != b, …) - Compare between date types (date1 < date2, date1>date2, date1!=date2, …) Do you think this CEP should also contain those? And, about your question, the answer is yes. Take a look at the Color example that I mentioned above: CREATE TYPE keyspace.color ( r int, g int, b int, CONSTRAINT r >= 0, CONSTRAINT r < 255, CONSTRAINT g >= 0, CONSTRAINT g < 255, CONSTRAINT b >= 0, CONSTRAINT b < 255, ) Here, you have more than one constraint per column to form a composite object. Similar things should be supported at table level. I hope this helps, Bernardo > On Jun 6, 2024, at 11:08 PM, Dinesh Joshi <djo...@apache.org> wrote: > > On Thu, Jun 6, 2024 at 1:50 PM Bernardo Botella <conta...@bernardobotella.com > <mailto:conta...@bernardobotella.com>> wrote: >> I will update the CEP being specific with the two specific Constraint types >> I will be adding, which are size and value (the ones shown in the example). > > Could you identify constraints for the most common data types? It would be > nice to ship a good set of default constraints. For example, it would be nice > to constrain numeric & date data types within a range, text could comply with > a pattern, etc. > > One question that I'm not sure if it came up, is whether a column could have > multiple constraints? > > Dinesh > >
