Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
HBase >> mail # dev >> HBase table truncate


+
Matteo Bertozzi 2013-04-10, 13:52
+
Ted Yu 2013-04-10, 14:01
+
Jean-Marc Spaggiari 2013-04-10, 14:04
+
Doug Meil 2013-04-10, 17:27
+
Matteo Bertozzi 2013-04-10, 17:35
Copy link to this message
-
Re: HBase table truncate

Thanks for the clarification.  Upon first read I thought that this was a
start of a discussion on putting writing a delete tombstone - I have had
too many "transactional delete vs. truncate data files" conversations and
I focused too much on that part.   :-)
On 4/10/13 1:35 PM, "Matteo Bertozzi" <[EMAIL PROTECTED]> wrote:

>On Wed, Apr 10, 2013 at 6:27 PM, Doug Meil
><[EMAIL PROTECTED]>wrote:
>
>>
>> re:  "truncate is supposed to be more like a "delete_all","
>>
>> In an RDBMS an "truncate" doesn't do "delete all", it actually whacks
>>the
>> underlying files to clear the table (or a particular partition, if you
>> happen to have an RDBMS that supports partitioning).
>>
>
>You've missed the important part "requiring just the ability to delete all
>the rows in the table" on purpose?
>Do you think that truncate should stay as it today requiring the same
>rights as "CREATE TABLE"?
>
>in this case, a use may be able to delete rows from the table but not run
>truncate the table
>because it doesn't have enough rights to recreate it.
+
Jonathan Hsieh 2013-04-10, 17:39
+
Enis Söztutar 2013-04-10, 17:50
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB