ctubbsii commented on code in PR #5498:
URL: https://github.com/apache/accumulo/pull/5498#discussion_r2056794643


##########
core/src/main/java/org/apache/accumulo/core/metadata/AccumuloNamespace.java:
##########
@@ -28,7 +28,7 @@
 /**
  * Defines the name and id of all tables in the accumulo table namespace.
  */
-public enum AccumuloTable {
+public enum AccumuloNamespace {

Review Comment:
   > I prefer to call them the system namespace / system tables, but that may 
be due to my experience with relational databases.. Having Table and Namespace 
objects for the public API might make sense at some point. Having an internal 
object that represents the objects necessary to maintain the system also makes 
sense, I think we just need the right naming.
   
   Would SystemTables make sense as a class name then? I am fine with it. 
Another way to say it is the accumulo namespace is reserved for system tables, 
or system tables reside in the accumulo namespace. These are synonymous, but 
the class name SystemTables makes it clear that it's a utility for system 
tables, but doesn't misrepresent itself as an abstraction for the namespace 
itself. I like it.
   
   > By the way, we also have an object called `RootTable` which mostly 
contains constants that could be in `Constants.java`.
   
   Yeah, there was an effort to try to localize a lot of narrowly-scoped 
constants to the code where they were relevant, rather than having a massive 
list of global constants, which was becoming unwieldy. I would like Constants 
to go away eventually, or only contain a couple global constants. We should be 
able to organize the constants that pertain to storage schemas into their 
respective abstraction layers, so callers don't have to know the schema 
themselves. I think that one is okay for now, but we may want to revisit once 
we do have a more general abstraction for tables for use internally.



-- 
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.

To unsubscribe, e-mail: notifications-unsubscr...@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to