hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Varley <ivar...@salesforce.com>
Subject Re: [DISCUSS] Namespace Delimiter
Date Tue, 07 May 2013 23:49:57 GMT
I would also submit that "." is a pretty universal standard (citation needed) in relational
databases for separating namespaces (schemas, etc.) from tables. We use that now to represent
the same idea, and using a different delimiter would be less than ideal in the long run.

But, I agree with Jon - anything in the 0.96 upgrade that causes people to change client code
in lock-step isn't going to fly.

Is there any solution which can use "." but be transparent at upgrade time? I.e. you could
still refer to it by its full "Namespace.Table" name in client code, and it does a little
more work to try both combinations? That'd prevent cases where someone already has tables
called both "Y' and "X.Y", but, come on, who does that?

Ian

On May 7, 2013, at 6:43 PM, Jonathan Hsieh wrote:

I prefer using a delimiter that does not require migration.  As someone who
has to support a wide variety of users, this will cause much less confusion
from our users (and save me grief!)

>From the code [1], any symbol char other than '.', '_', or '-' would be an
ok delimiter.  howabout a ':' or '#'?

[1]
https://github.com/apache/hbase/blob/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java#L415

Jon.


On Tue, May 7, 2013 at 4:38 PM, Francis Liu <toffer@apache.org> wrote:

Hi,

As part of the namespace patch (HBASE-8015). We will need a delimiter to
separate namespace name from table name. The obvious choice here would be a
dot '.'. Since dot is presently a valid character for table names that
would require users to migrate their tables (ie renaming tables) as part of
upgrade to 0.96. Another option is to use a different delimiter to avoid
the table migration altogether. Thoughts?

-Francis




--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message