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