Home | About | Sematext search-lucene.com search-hadoop.com
 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
Ted Yu 2013-05-09, 01:27
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.
> > >>>
> > >>
> > >>
> >
> >
>