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 Threaded View
HBase >> mail # dev >> [DISCUSS] Namespace Delimiter


Copy link to this message
-
Re: [DISCUSS] Namespace Delimiter
> I think putting existing tables with "." in table name as part of default
> namespace is better choice among the two.

Correct me if I missed something here. That is probably the more difficult of the two as you can't derive membership information by just parsing the table name. Which is what is passed around internally most of the time. Because of that I prefer the auto namespace generation approach.

On May 8, 2013, at 5:11 PM, Ted Yu wrote:

> bq. by recognizing existing tables with "." as part of the default
> namespace or automatically create namespaces for tables with dots in them.
>
> I think putting existing tables with "." in table name as part of default
> namespace is better choice among the two.
>
> Cheers
>
> On Wed, May 8, 2013 at 5:02 PM, Francis Liu <[EMAIL PROTECTED]> wrote:
>
>> There shouldn't be any ambiguity. There's fully-qualified table names and
>> there's table names.  Table name constant changes were to make the names
>> less funky.
>>
>> I like your suggestion since it simplifies migration. Though it seems
>> we're kicking the can down the road here. In a way we're avoiding the
>> problem by specifying an internal delimiter and adding extra complexity to
>> prevent the user from using it. Having a way of specifying a table fully
>> qualified seems to be something fundamental and convenient, if we don't
>> support one now we'll have even more trouble in the future. Looking at the
>> suggestions we can potentially make migration painless by recognizing
>> existing tables with "." as part of the default namespace or automatically
>> create namespaces for tables with dots in them. Neither requires renaming
>> tables. They only need to rename tables if they want to start organizing
>> things into namespaces which they will have to do in any scenario.
>>
>> -Francis
>>
>> On May 8, 2013, at 1:27 PM, Elliott Clark wrote:
>>
>>> 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.
>>>
>>
>>
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