Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> [DISCUSS] Namespace Delimiter


+
Francis Liu 2013-05-07, 23:38
+
Jonathan Hsieh 2013-05-07, 23:43
+
Ian Varley 2013-05-07, 23:49
+
Francis Liu 2013-05-08, 00:22
+
Stack 2013-05-08, 06:36
+
James Taylor 2013-05-08, 06:55
+
Sergey Shelukhin 2013-05-08, 19:01
Copy link to this message
-
Re: [DISCUSS] Namespace Delimiter
I've said most of this on the jira but I'll add it to the discussion here.

Allowing table names with dots is easy if we just add a parameter.

HTable(Configuration conf, final String tableName) will just assume
the default.  (This keeps all backwards compatibility for everything
but meta.)
HTable(Configuration conf, final String tableName, String nameSpace)
is added.  This allows namespaces to have naming very similar to
tables (more flexibility for users is better imo).

The shell gets an optional namespace parameter added on to lots of the
commands.  If it's there then take the namespace.  If it's not then
assume default.  Just like HTable this keeps backwards compatibility
for everything but meta.  Yes this is the messiest part, but it's the
least important imo.  The java api is what should be the prime focus.
Let others add a SQL like (or full sql) shell on top of HBase.  We
shouldn't make using the java api more confusing for users who are
used to our api, just so that HBase can be like sql.

Meta's pretty easy.  We already use a comma as a separator for
different parts of the key.

Zk can be handled in much the same way as meta (with a separator
that's already not legal table name).

With this solution there's no naming ambiguity.  There's no
overloading table name to actually be two different things.  There's
no need for users to rename their tables. Most code that is already
written will still be source compatible.  No need to change table name
constants or anything like that.

On Wed, May 8, 2013 at 12:01 PM, Sergey Shelukhin
<[EMAIL PROTECTED]> wrote:
> I think if we want to use a dot, we need to be able to support both old
> tables with dot, and table in namespace. Consequently parsing should not
> rely on a dot or store "truth" info about NS tables as one string with a
> dot, I lost track of the patch a while ago but I think it was considered at
> some point...
> I thought about it a bit and I think the order of resolution should be
> old-dot-table overriding namespace table. Creating tables with a dot should
> not be allowed. Creating tables in namespace that would be shadowed by
> legacy old tables should not be allowed too (e.g. if you have old table
> "foo.bar" trying to create table "bar" in ns "foo" would cause an error).
>
> So users have no inconvenience with legacy tables, and only get
> inconvenienced in a very explicit way if they use namespaces in a certain
> way.
>
>
>
>
> On Tue, May 7, 2013 at 11:55 PM, James Taylor <[EMAIL PROTECTED]>wrote:
>
>> Phoenix uses  <schema name> . <table name> to reference tables, so
>> allowing a "." in names would make parsing ambiguous.
>>
>>     James
>>
>>
>> On 05/07/2013 11:36 PM, Stack wrote:
>>
>>> On Tue, May 7, 2013 at 5:22 PM, Francis Liu <[EMAIL PROTECTED]> wrote:
>>>
>>>  One thing I had in mind was to automatically assume that the first dot
>>>> delimits the namespace name. During upgrade we automatically create those
>>>> namespaces and assign the tables accordingly. They can then eventually
>>>> migrate/rename their tables (if needed) at a later time. In the extreme
>>>> case that would be one namespace per table. For which we will provide a
>>>> tool to rename offline tables.
>>>>
>>>> I'm guessing most cases would not require a rename. What else do people
>>>> use dots in their table name for?
>>>>
>>>>
>>> With namespaces in place, will '.' be illegal in a table name?
>>>
>>> With namespaces, is there a no-namespace/default location?  If so, what
>>> will it be called or how will you refer to tables in the
>>> no-namespace/default namespace?
>>>
>>> I just took a user's production website where there are hundreds of
>>> tables.
>>>   For no good reason that I can see, they happened to have choosen '_' and
>>> '-' as table name partitioner: i.e. application_feature, etc.  My sense is
>>> they could just as easily have gone with '.' but maybe the '.META.' name
>>> frightens people away from '.'?
>>>
>>> Anyone using '.' in their table names?
>
+
Francis Liu 2013-05-09, 00:02
+
Ted Yu 2013-05-09, 00:11
+
Francis Liu 2013-05-09, 01:00
+
Sergey Shelukhin 2013-05-09, 01:24
+
Francis Liu 2013-05-09, 01:36
+
Ted Yu 2013-05-09, 01:27
+
Francis Liu 2013-05-09, 01:58
+
Ted Yu 2013-05-09, 02:03
+
Stack 2013-05-09, 03:40
+
Francis Liu 2013-05-09, 23:03
+
Ted Yu 2013-05-09, 23:21
+
Francis Liu 2013-05-09, 23:43
+
Enis Söztutar 2013-05-10, 01:00
+
Francis Liu 2013-05-10, 01:44
+
Elliott Clark 2013-05-10, 16:25
+
Ted Yu 2013-05-09, 01:15
+
Enis Söztutar 2013-05-08, 18:54
+
James Taylor 2013-05-08, 19:02
+
Francis Liu 2013-05-08, 23:07
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB