Home | About | Sematext search-lucene.com search-hadoop.com
 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
Francis Liu 2013-05-09, 01:58
> 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