Paul explained one symptom in HIVE-1435.

For the other, the way to repro it is to start from a clean checkout  
from before HIVE-1176 was committed, build there and run build/dist/ 
bin/hive to init the metastore.  Then svn update to the tip of trunk,  
build again, and run hive CLI again; this time you will hit a startup  
error when it tries to modify the existing Derby database.

I think Paul's HIVE-1435 patch will resolve both.

JVS


On Jun 24, 2010, at 7:35 PM, "Arvind Prabhakar" <arv...@cloudera.com>  
wrote:

> John,
>
> Can you describe the problem in more detail and perhaps give us an  
> example
> that can be reproduced?
>
> Arvind
>
> On Thu, Jun 24, 2010 at 7:01 PM, John Sichi <jsi...@facebook.com>  
> wrote:
>
>> Hi all,
>>
>> Yesterday I committed Arvind's patch for HIVE-1176, which includes an
>> upgrade from datanucleus 1.x to 2.x.
>>
>> The patch works fine against a clean checkout, but just now Paul  
>> Yang and I
>> noticed a couple of problems introduced due to a change in the way  
>> column
>> names are generated by datanucleus when no name is specified in the  
>> JDO
>> mapping (which is the case for some of ours such as  
>> "isCompressed").  This
>> is a heads-up for people who happen to pull from latest trunk.
>>
>> The problems only occur when running against an existing metastore,  
>> for
>> example if you run trunk/build/dist/bin/hive against a new build in  
>> an
>> existing sandbox (where a Derby embedded metastore had previously  
>> been
>> created), or if you deploy against an existing production metastore  
>> DB.
>>
>> In a developer sandbox, the default configuration tries to auto- 
>> update the
>> schema to add the new column names, and hits an error due to the  
>> way the
>> Derby ALTER TABLE statement is generated.  If you hit this, a  
>> workaround is
>> to delete your trunk/metastore_db directory so that a fresh schema  
>> will be
>> recreated instead.  Or just move to a fresh checkout.
>>
>> Paul is taking a look at the column name generation to see if we  
>> can get it
>> to match the datanucleus 1.x behavior.
>>
>> JVS
>>
>>

Reply via email to