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