Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
Date: Mon, 15 Dec 2014 22:06:43 -0500
Message-ID: 
 <CAGoyRrPw1eVx5cAFJ8ww5fPZkieZJ6MzeDBuvspAwRc64rcWiw@mail.gmail.com>
Subject: Namespaces & Application Classpath interplay
From: Chris Bennight <chris@slowcar.net>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=001a1140faac0f0a6b050a4ca677

--001a1140faac0f0a6b050a4ca677
Content-Type: text/plain; charset=UTF-8

(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

--001a1140faac0f0a6b050a4ca677--