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
> Francis, your proposal for auto-generating the namespaces looks good, but I
> am wondering whether the user might be surprised later when they find about
> the all the namespaces.
The ones that don't read the release notes will probably be surprised though I don't think it'll be a big issue.
As it doesn't affect existing behavior, apart from not being able to create new tables with dots.
And they only have to do extra work if they choose to start using namespaces the way it should be.

> BTW, renaming a table will break snapshots, unless it is done as a clone /
> restore.

I see, clone/restore was one approach I had in mind to implement renaming.

On May 9, 2013, at 6:00 PM, Enis Söztutar wrote:

> Elliot's suggestion sounds good, but unfortunately there are places where
> we use the table name as a string. We cannot expect all those places to
> also have namespaces. Some of the examples are metrics names per table,
> hfile links encoding the table name in it, and maybe znodes, and of course
> the shell. I would agree though that we should handle the schama and table
> names as separate entities within inside hbase.
>
> Francis, your proposal for auto-generating the namespaces looks good, but I
> am wondering whether the user might be surprised later when they find about
> the all the namespaces.
>
> BTW, renaming a table will break snapshots, unless it is done as a clone /
> restore.
>
>
>
>
>
>
> On Thu, May 9, 2013 at 4:43 PM, Francis Liu <[EMAIL PROTECTED]> wrote:
>
>> I can probably incorporate the migration into the main patch will see how
>> big it gets. And the rename tool as a subtask.
>>
>> On May 9, 2013, at 4:21 PM, Ted Yu wrote:
>>
>>> The plan is feasible.
>>> This would be done in sub-task of HBASE-8015, right ?
>>>
>>> Thanks
>>>
>>> On Thu, May 9, 2013 at 4:03 PM, Francis Liu <[EMAIL PROTECTED]> wrote:
>>>
>>>> Sounds like I should give the auto-generate approach a try.
>>>>
>>>> In essence it'll do the following:
>>>>
>>>> - Tables without '.' will be moved into the default namespace.
>>>> - Tables with '.' will be move into new namespaces
>>>>       - namespaces will be delimited by the last '.' in the table name
>>>>               ie org.apache.hbase.MyTable, namespace = org.apache.hbase
>>>> - In both cases the oldTableName is the same as the fullTableName
>>>> - all existing apis and cli commands will be expecting full table names
>>>> unless explicitly stated
>>>> - a RenameTable tool will be provided to rename offline tables
>>>>
>>>> Let me know if any clarification is needed.
>>>>
>>>> -Francis
>>>>
>>>>
>>>> On May 8, 2013, at 8:40 PM, Stack wrote:
>>>>
>>>>> On Wed, May 8, 2013 at 7:03 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> w.r.t. auto-generate option, we need some heuristics.
>>>>>>
>>>>>> e.g. would namespace.schemaname.tablename be supported ?
>>>>>>
>>>>>> The auto-generate option may create namespace name out of existing
>>>> schema
>>>>>> name.
>>>>>>
>>>>>
>>>>>
>>>>> There is no schema name in hbase.  James's convention up in phoenix at
>>>> the
>>>>> hbase-level is a table name w/ a dot in it.
>>>>>
>>>>> This is already a difficult enough issue.  No need to add
>> complications.
>>>>>
>>>>> St.Ack
>>>>
>>>>
>>
>>
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