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
+
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
+
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
Copy link to this message
-
Re: [DISCUSS] Namespace Delimiter
bq. as you can't derive membership information by just parsing the table
name.

Can we store additional information, at migration time, in system.namespace
table so that namespace membership can be determined without ambiguity ?

Cheers

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