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