[
https://issues.apache.org/jira/browse/CASSANDRA-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14625968#comment-14625968
]
Sylvain Lebresne commented on CASSANDRA-9745:
---------------------------------------------
bq. We want "real" triggers anyway, though.
I agree but I think it's a different ticket. I can see how triggers can be used
to do validation, but it's also not the most direct/use friendly way to do it
imo. And being able to define more precise db-enforced constraints on the
schema easily is imo a nice thing to have. Not going though the triggers
machinery for that might also be more efficient.
bq. I'm not a fan of using UDFs for anything internal.
I don't want to make it sound like I think UDF is an absolute component of this
ticket, I mostly just wanted to say that we could and should add a bit more
expressive validation for values that just our current types, and so I've
slightly generalized the title of this ticket.
I'm also fine with using {{CHECK}} constraints for this, if only because the
proper way to implement this will be to reuse our {{ColumnFilter}}
implementation and that will ultimately give us UDFs for free (but you'll still
be able to do the most common validation without it, so you'll be happy).
> Better validation for values
> ----------------------------
>
> Key: CASSANDRA-9745
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9745
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Sylvain Lebresne
> Priority: Minor
> Fix For: 3.x
>
>
> The only server side validation we do for values is currently that they match
> their type. Now that we have UDFs, we could allow to optionally specify a
> (boolean) value validation function on a per-column basis. This would give us
> a pretty generic way of validating value, which sounds useful to me.
> Once we have that, we could even add some syntactic sugar for some common
> type of validations, like {{v int[0..100]}} for numbers between 0 and 100, or
> {{v text[20]}} for a string that is not longer than 20, ... That's more of a
> follow up however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
