HBASE-451 Remove HTableDescriptor from HRegionInfo
Review Request #849 - Created June 2, 2011 and updated
Posting for Subbu See issue for his description of change.
This looks excellent. Lets get it committed before it rots. Do we still need .regioninfo after this goes in?
WhooHoo... this is starting out good! I think you should take the opportunity of changing HRI to be a VersionedWritable.
Excellent! (HRI not having ref to HTD)
This works? Thats interesting.
When would this be used?
This should not be allowed? Are you not going to mess up stuff if table gets changed on an HRI?
Should these be deprecated rather than removed? Even if we returned a null only?
This is perverse, begin able to change the HTD under an HRI. Can't believe this actually was allowed exist.
You could just do an equals since its boolean... Bytes.equals...
This is incorrect. Should be isMetaTable() or isRootRegion... a 'meta' region is a .META. or -ROOT- member.
Put this into a migration subpackage?
Oh, so what is this? Its old-school HRI? If so, call it HRI090? Or if you have it in a subpackage migration, it can have same name and just be fully specified whereever it is used.. the migration subpackage will make it explicity taht this is not same as new HRI.
This is from elsewhere? Does it belong here?
I don't think we should do this by default. What if KV has a value of MBs?
What if we crash half-way through migration? We should be able to deal w/ a .META. that is half the old style HRI and half the new style?
You want to leave these in place?
What a crazy way of getting HTDs.
Do we need these last two? Can't we use this first method to get the latter?
Is this going to the FS to read tables? And we're holding sync while we are doing it? Is that necessary?
This method belongs in master since its going to run the migration?
Close the file?
Good. The human readable version is included.
I wonder if you have to create the file elsewhere and then do a rename to put it in place? Else if crash, could be half-written? Do we do this w/ .regioninfo?