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