Raghu Angadi commented on PIG-993:

I think the test needs to be fixed.  It deletes 6 column groups from 6 
different threads. The spec explicitly states read accesses and parallel 
deletions expected to fail. But the table is always left in consistent state. 
The rationale for this is that in practice these tables are accessed from 
different machines and it would add unnecessary complication to support 
coordinate all the readers and the writers (especially with no locking support 
on HDFS). Zebra tables have no state outside the directory. This applies to 
writing as well.

One options I see is to make each thread make multiple attempts in case of 

> [zebra] Abitlity to drop a column group in a table
> --------------------------------------------------
>                 Key: PIG-993
>                 URL: https://issues.apache.org/jira/browse/PIG-993
>             Project: Pig
>          Issue Type: Bug
>            Reporter: Raghu Angadi
>            Assignee: Raghu Angadi
>             Fix For: 0.6.0
>         Attachments: DropColumnGroupExample.java, 
> TEST-org.apache.hadoop.zebra.io.TestCheckin.txt, zebra-drop-cg.patch, 
> zebra-drop-cg.patch, zebra-drop-cg.patch
> A Zebra table is stored as multiple sub tables each containing a set of 
> columns called column group (CG). The user specifies how these columns are 
> grouped while creating a table through the _storage hint_.
> For some of the large tables, it might be necessary for users to remove a set 
> of columns and retain the rest. This jira provides a way for users to delete 
> an entire column group. 
> The following comments will have more details on API and the semantics. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to