In essence, you're asking to apply some context classloader to a
namespace and have it propagate down to each table in that namespace as
opposed to setting it on each table? By doing so, you wouldn't have to
ensure that each table for your logical "application" is configured with
the same context classloader.
If that's the case, +1 for the change -- nearly all of our properties
already "delegate" in that fashion: per-table inherits from namespace
which inherits from system. I'm a little sad if it doesn't actually
already do it (because that means classloader configuration is an edge
case internally), but happy that you'd like to work on it :)
Chris Bennight wrote:
(Note - my assumption here is that I can't currently assign an isolated
classpath as "default" for a particular namespace; if I missed something
apologies)
So I get the ability to assign an application specific classpath on a per
table basis. In my case I create (and sometimes remove) tables via the API
(as opposed to the shell) - which scope normally mediated by a namespace.
I can attach an application classpath at creation to each table, but this
requires sharing information (name of application classpath somehow
configured/set for application), or convention (always call it "xyz")
between the accumulo config and client application.
I think a cleaner solution in this part would be to let the classpath be
tied through accumulo configuration to the namespace (this would also make
classpath isolation easier for other programs - they don't have to add in
hooks in the case of programatically creating tables).
So my questions:
-- Is this something that is already in the works? (I swear, I looked in
JIRA)
-- Is it a terrible idea (why?)
-- If it's not already done, and not a bad idea, should I create a ticket,
propose a design, and start coding after vetting?
Thanks,
Chris
