keith-turner commented on a change in pull request #2122:
URL: https://github.com/apache/accumulo/pull/2122#discussion_r645665149
##########
File path:
core/src/main/java/org/apache/accumulo/core/client/admin/NamespaceOperations.java
##########
@@ -202,11 +202,32 @@ void removeProperty(String namespace, String property)
* if the user does not have permission
* @throws NamespaceNotFoundException
* if the specified namespace doesn't exist
- * @since 1.6.0
+ * @deprecated since 2.1.0; use {@link #getPropertiesMap(String)} instead.
*/
+ @Deprecated(since = "2.1.0")
Review comment:
My thoughts on deprecating are not super well defined, but my thinking
on deprecation of API is that it should be related to functionality that will
be removed or is fundamentally broken. For this particular case the
functionality behind the existing API in questions works fine and will not be
removed. Also the new API being introduced is functionally equivalent to the
existing API (each could be fully implemented using only the other). We could
introduce an infinite number of functionally equivalent APIs and deprecate
existing APIs.
Unrelated to deprecation, I also tend to think that new APIs should normally
be motivated by new functionality. However its not that well defined for me,
because I can think of exceptions to this guide. In this case there is no new
functionality, but the new API sill makes sense to me for other reasons.
Thinking about this a bit more, it makes me wonder if there are any new
functional changes related to configuration on the horizon. If so could those
require new APIs? If that were the case it may be prudent to wait on this
change and consider it w/ that new functionality.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
