I sort-of ran out of time for the near term, but will look into all these suggestions at a later date. Thanks!
On Thu, Feb 25, 2016 at 1:01 PM, James Taylor <[email protected]> wrote: > +1 to Ankit's suggestion. If you haven't altered the table, then you can > just connect at the timestamp of one more than the timestamp at which the > table was created (see [1]), and issue to DROP TABLE command from that > connection. If you have altered the table, then you have to be more careful > as their may be data that is older than when you altered the table. It's > easy to find out, though. Just connection as mentioned above, and run this: > > SELECT COUNT(*) FROM your_table > > If the count returns 0, then you won't lose any data when you issue the > DROP TABLE command. > > Also, FWIW, you can drop a view and this has no impact on your data. So > you could always work through views and just leave the base table alone. > > Thanks, > James > > > [1] > https://phoenix.apache.org/faq.html#Can_phoenix_work_on_tables_with_arbitrary_timestamp_as_flexible_as_HBase_API > > On Thu, Feb 25, 2016 at 10:21 AM, Jonathan Leech <[email protected]> > wrote: > >> If I understand what you're attempting to do, I think a snapshot will >> work. A snapshot is not a copy of the data and doesn't take much time. It's >> really just a copy of the region-> store files mapping at a point in time. >> It will prevent the store files from getting deleted so drop the snapshot >> once you're done with it. As long as there's no difference in the >> representation of the Phoenix data in hbase for dynamic column data vs >> explicit columns, you should be able to take the snapshot, drop the table, >> recreate it with the new definition, then restore the snapshot. >> >> >> >> On Feb 25, 2016, at 8:44 AM, Steve Terrell <[email protected]> wrote: >> >> I like your outside-the-box thinking. Unfortunately, my end goal was to >> convert a table created with dynamic fields into a table or view with all >> static fields so that I could avoid having to specify the data type of >> every dynamic field in the SQL. And I wanted to avoid having to rewrite >> the data - which is what I would have to do if I copied to a new table or >> do a snapshot/restore. >> >> If I go forward, it looks like I'll probably need to just create a new >> table with all fields made static, and then copy the data from one to the >> other. >> >> Thanks, >> Steve >> >> On Wed, Feb 24, 2016 at 7:11 PM, Jonathan Leech <[email protected]> >> wrote: >> >>> You could also take a snapshot in hbase just prior to the drop table, >>> then restore it afterward. >>> >>> >>> >>> On Feb 24, 2016, at 12:25 PM, Steve Terrell <[email protected]> >>> wrote: >>> >>> Thanks for your quick and accurate responses! >>> >>> On Wed, Feb 24, 2016 at 1:18 PM, Ankit Singhal <[email protected] >>> > wrote: >>> >>>> Yes, data will be deleted during drop table command and currently there >>>> is no parameter to control that. You may raise a jira for this. >>>> >>>> A workaround you may try is by opening a connection at a timestamp a >>>> little greater than last modified timestamp of table and then run drop >>>> table command. but remember you may still loose some data inserted before >>>> that timestamp >>>> >>>> Regards, >>>> Ankit Singhal >>>> >>>> On Wed, Feb 24, 2016 at 11:27 PM, Steve Terrell <[email protected]> >>>> wrote: >>>> >>>>> Good idea! >>>>> >>>>> I was using SQuirreL Client, and I did put the hbase-site.xml in the >>>>> same directory as the driver jar. However, I did not know how to check to >>>>> see that the property was being found. >>>>> >>>>> So, I switched to using the sqlline query command line, and this time >>>>> the table remained in the hbase shell list after I dropped it in Phoenix. >>>>> So, when using sqlline I am sure that the property is being picked up. >>>>> I'll worry about SQuirreL another day. >>>>> >>>>> Now I have a new problem: Even though the table still exists in >>>>> HBase, the data that I had upserted into the table via Phoenix does not >>>>> show up when I *scan* it in *hbase shell*. Looks like the drop table >>>>> in Phoenix also deleted my rows in HBase. >>>>> >>>>> Is there a way to drop the Phoenix table without the rows in HBase >>>>> being deleted? >>>>> >>>>> Thank you, >>>>> Steve >>>>> >>>>> >>>>> On Wed, Feb 24, 2016 at 11:42 AM, Ankit Singhal < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Steve, >>>>>> >>>>>> can you check whether the properties are picked by the >>>>>> sql/application client. >>>>>> >>>>>> Regards, >>>>>> Ankit Singhal >>>>>> >>>>>> On Wed, Feb 24, 2016 at 11:09 PM, Steve Terrell < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> HI, I hope someone can tell me what I'm doing wrong… >>>>>>> >>>>>>> I set *phoenix.schema.dropMetaData* to *false* in hbase-site.xml on >>>>>>> both the client and server side. >>>>>>> >>>>>>> I restarted the HBase master service. >>>>>>> >>>>>>> I used Phoenix to create a table and upsert some values. >>>>>>> >>>>>>> I used Phoenix to drop the table. >>>>>>> >>>>>>> I expected the table to still exist when I went into *hbase shell* >>>>>>> and did a *list*, but the table apparently was dropped from HBase >>>>>>> as well. >>>>>>> >>>>>>> Did I miss something? >>>>>>> >>>>>>> Thank you, >>>>>>> Steve >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
