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
+
Francis Liu 2013-05-09, 01:58
Copy link to this message
-
Re: [DISCUSS] Namespace Delimiter
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.

Cheers

On Wed, May 8, 2013 at 6:58 PM, Francis Liu <[EMAIL PROTECTED]> wrote:

> > 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.
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
>
>
+
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