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
+
Elliott Clark 2013-05-08, 20:27
+
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
Copy link to this message
-
Re: [DISCUSS] Namespace Delimiter
> Looks like using '#' as delimiter becomes an attractive option.

Doesn't the auto-generate option sound reasonable?

On May 8, 2013, at 6:27 PM, Ted Yu wrote:

> bq. use different internal separator that will not cause backward compat
> and change it for display only.
>
> User would copy / paste table name from UI and expect it to be accepted by
> shell, etc.
>
> Looks like using '#' as delimiter becomes an attractive option.
>
> On Wed, May 8, 2013 at 6:24 PM, Sergey Shelukhin <[EMAIL PROTECTED]>wrote:
>
>> I think if we only have a string for fully qualified table name internally
>> and rely on parsing the dot we are going to have migration issues
>> somewhere.
>> Externally I agree with Elliot, we can do all kinds of things like add
>> parameters, but internally IMHO we need separate namespace argument, or if
>> it is too painful, use different internal separator that will not cause
>> backward compat and change it for display only.
>>
>> On Wed, May 8, 2013 at 6:00 PM, Francis Liu <[EMAIL PROTECTED]> wrote:
>>
>>>> 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.
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
+
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