I committed Paul's HIVE-1435 patch last night, so trunk should be OK now.  

JVS
________________________________________
From: John Sichi
Sent: Thursday, June 24, 2010 8:28 PM
To: <hive-dev@hadoop.apache.org>
Cc: hive-u...@hadoop.apache.org; hive-dev@hadoop.apache.org
Subject: Re: JDO upgrade issue with HIVE-1176

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