hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Steinbach <c...@cloudera.com>
Subject Re: release 0.6
Date Thu, 07 Oct 2010 01:45:01 GMT
Hi Namit,

Sounds like a good plan to me.

Carl

On Wed, Oct 6, 2010 at 2:04 PM, Namit Jain <njain@facebook.com> wrote:

> Carl,
>
> Now that all the blocking jiras for 0.6 have been committed, can we release
> 0.6, say end of the week ?
> We can give some notice to people if they want to file a blocker in the
> next 2-3 days.
>
>
>
> Thanks,
> -namit
>
>
> ________________________________________
> From: Namit Jain [njain@facebook.com]
> Sent: Friday, October 01, 2010 9:44 AM
> To: Carl Steinbach
> Cc: hive-dev@hadoop.apache.org
> Subject: RE: release 0.6
>
> I am not sure what kind of downtime would it involve for us (facebook).
>
> We will have to make a copy of the production metastore, and then perform
> the changes.
> If that takes a long time, we will have to come up with some quicker
> upgrade solutions -
> We will try to do that today, and get back to you.
>
>
> Thanks,
> -namit
>
>
> From: Carl Steinbach [mailto:carl@cloudera.com]
> Sent: Thursday, September 30, 2010 11:23 PM
> To: Namit Jain
> Cc: hive-dev@hadoop.apache.org
> Subject: Re: release 0.6
>
> Hi Namit,
> It used to be much higher in the beginning but quite a few users reported
> problems on some mysql dbs. 767 seemed to work most dbs. before committing
> this can someone test this on some different dbs (with and without UTF
> encoding)?
>
> Copying my response to Prasad from HIVE-1364:
> "It's possible that people who ran into problems before were using a
> version of MySQL older than 5.0.3. These versions supported a 255 byte max
> length for VARCHARs. It's also possible that older versions of the
> package.jdo mapping contained more indexes, in which case the 767 byte limit
> holds. Also, UTF encoding should not make a difference since these are byte
> lengths, not character lengths."
>
> Another point is that HIVE-675 added two 4000 byte VARCHARs to the mapping,
> and this patch is present in both trunk and the 0.6.0 branch. I haven't
> heard that anyone is experiencing problems because of this.
>
> Do we really need it for 0.6, or should we test it properly/take our time
> and then commit it if needed.
>
> Yes, I think we really need these changes. Several people have already
> commented on the list about hitting the 767 byte limit while using the HBase
> storage handler.
>
> What kind of testing regimen do think is necessary for this change?
>
> Thanks.
>
> Carl
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message