* Metrics are created from a HRegion so they can have the namespace pretty easily. * Hfile links would be relative to the namespace unless explicit, so there's no issue there. * I showed how znodes could be handled. * I also had examples for the shell.
It seems like Francis is going ahead with namespace auto-generation so I'll hold my concerns until we see what the implementation looks like. On Thu, May 9, 2013 at 6:44 PM, Francis Liu <[email protected]> wrote: >> Francis, your proposal for auto-generating the namespaces looks good, but I >> am wondering whether the user might be surprised later when they find about >> the all the namespaces. > > > The ones that don't read the release notes will probably be surprised though > I don't think it'll be a big issue. > As it doesn't affect existing behavior, apart from not being able to create > new tables with dots. > And they only have to do extra work if they choose to start using namespaces > the way it should be. > >> BTW, renaming a table will break snapshots, unless it is done as a clone / >> restore. > > I see, clone/restore was one approach I had in mind to implement renaming. > > On May 9, 2013, at 6:00 PM, Enis Söztutar wrote: > >> Elliot's suggestion sounds good, but unfortunately there are places where >> we use the table name as a string. We cannot expect all those places to >> also have namespaces. Some of the examples are metrics names per table, >> hfile links encoding the table name in it, and maybe znodes, and of course >> the shell. I would agree though that we should handle the schama and table >> names as separate entities within inside hbase. >> >> Francis, your proposal for auto-generating the namespaces looks good, but I >> am wondering whether the user might be surprised later when they find about >> the all the namespaces. >> >> BTW, renaming a table will break snapshots, unless it is done as a clone / >> restore. >> >> >> >> >> >> >> On Thu, May 9, 2013 at 4:43 PM, Francis Liu <[email protected]> wrote: >> >>> I can probably incorporate the migration into the main patch will see how >>> big it gets. And the rename tool as a subtask. >>> >>> On May 9, 2013, at 4:21 PM, Ted Yu wrote: >>> >>>> The plan is feasible. >>>> This would be done in sub-task of HBASE-8015, right ? >>>> >>>> Thanks >>>> >>>> On Thu, May 9, 2013 at 4:03 PM, Francis Liu <[email protected]> wrote: >>>> >>>>> Sounds like I should give the auto-generate approach a try. >>>>> >>>>> In essence it'll do the following: >>>>> >>>>> - Tables without '.' will be moved into the default namespace. >>>>> - Tables with '.' will be move into new namespaces >>>>> - namespaces will be delimited by the last '.' in the table name >>>>> ie org.apache.hbase.MyTable, namespace = org.apache.hbase >>>>> - In both cases the oldTableName is the same as the fullTableName >>>>> - all existing apis and cli commands will be expecting full table names >>>>> unless explicitly stated >>>>> - a RenameTable tool will be provided to rename offline tables >>>>> >>>>> Let me know if any clarification is needed. >>>>> >>>>> -Francis >>>>> >>>>> >>>>> On May 8, 2013, at 8:40 PM, Stack wrote: >>>>> >>>>>> On Wed, May 8, 2013 at 7:03 PM, Ted Yu <[email protected]> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>> >>>>>> >>>>>> There is no schema name in hbase. James's convention up in phoenix at >>>>> the >>>>>> hbase-level is a table name w/ a dot in it. >>>>>> >>>>>> This is already a difficult enough issue. No need to add >>> complications. >>>>>> >>>>>> St.Ack >>>>> >>>>> >>> >>> >
