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