[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v8.txt
Another version (v8) with merge conflicts resolved.
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt,
7813v5.txt, 7813v6.txt, 7813v7.txt, 7813v8.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v7.txt
Attached v7 (merge with trunk + merge conflicts resolved, no other changes)
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt,
7813v5.txt, 7813v6.txt, 7813v7.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v6.txt
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt,
7813v5.txt, 7813v6.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: (was: 7813v6.txt)
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt, 7813v5.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v6.txt
Attached v6 of the patch with the NIT's corrected and prepared statement
removal implemented. Prepared statement removal is also necessary when a new
function is created since matching of arguments (implicit casts) might change.
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt,
7813v5.txt, 7813v6.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v5.txt
Attached v5 of patch that fixes an inconsistency with upper/lower case function
names (quoted=keep case, unquoted=toLowerCase).
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt, 7813v5.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: (was: 7813v5.txt)
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt, 7813v5.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v5.txt
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt, 7813v5.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v4.txt
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: (was: 7813v4.txt)
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v4.txt
Thanks for the review. Worked on all points with some notes:
* Reverted checking of UDF creation in {{system_auth}} and {{system_traces}}
and use {{ThriftValidation.validateKeyspaceNotSystem}} (which only checks for
system KS). I've created CASSANDRA-8197 to cover inconsistent case-sensitivity
of {{system_auth}} and {{system_traces}}. It might make sense to create UDFs in
{{system_auth}} and {{system_traces}} (e.g. aggregations).
* {{DROP KEYSPACE}} did not propagate to {{system.schema_functions}}
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt, 7813v4.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-7813:
--
Reviewer: Benjamin Lerer
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v3.txt
updated patch (v2 has merge conflicts)
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt, 7813v3.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813v2.txt
Updated patch v2 (merge conflicts after removing UDF class functionality)
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt, 7813v2.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp updated CASSANDRA-7813:
Attachment: 7813.txt
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Robert Stupp
Labels: cql
Fix For: 3.0
Attachments: 7813.txt
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-7813:
Assignee: Benjamin Lerer
Decide how to deal with conflict between native and user-defined functions
--
Key: CASSANDRA-7813
URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
Project: Cassandra
Issue Type: Improvement
Reporter: Sylvain Lebresne
Assignee: Benjamin Lerer
Labels: cql
Fix For: 3.0
We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
3.0, user will be able to define new functions. Now, there is a very high
change that we will provide more native functions over-time (to be clear, I'm
not particularly for adding native functions for allthethings just because we
can, but it's clear that we should ultimately provide more than what we
have). Which begs the question: how do we want to deal with the problem of
adding a native function potentially breaking a previously defined
user-defined function?
A priori I see the following options (maybe there is more?):
# don't do anything specific, hoping that it won't happen often and consider
it a user problem if it does.
# reserve a big number of names that we're hoping will cover all future need.
# make native function and user-defined function syntactically distinct so it
cannot happen.
I'm not a huge fan of solution 1). Solution 2) is actually what we did for
UDT but I think it's somewhat less practical here: there is so much types
that it makes sense to provide natively and so it wasn't too hard to come up
with a reasonably small list of types name to reserve just in case. This
feels a lot harder for functions to me.
Which leaves solution 3). Since we already have the concept of namespaces for
functions, a simple idea would be to force user function to have namespace.
We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
