Hi Olga,
> Switching everybody to HiveServer2 has performance and scale consequences
> that might not be acceptable for every use case.
>
Just wanted to make sure you're aware that it's possible to run HiveServer2
in a thick-client mode where it sits embedded in the client JVM process.
This allo
ask to decouple Hive 1.0 discussion from removing CLI.
Thanks,
Olga
-Original Message-
From: Thejas Nair [mailto:the...@hortonworks.com]
Sent: Saturday, December 06, 2014 12:59 PM
To: dev@hive.apache.org
Subject: Re: Apache Hive 1.0 ?
I don't know for sure if beeline has fi
FYI that it's pretty close in terms of functionality. Dong and Ferdinand
have done a ton of work here.
On Sat, Dec 6, 2014 at 12:58 PM, Thejas Nair wrote:
> I don't know for sure if beeline has finally reached feature parity
> with hive cli. I haven't looked at that very closely. I think we
> sh
I don't know for sure if beeline has finally reached feature parity
with hive cli. I haven't looked at that very closely. I think we
should start a separate thread on it and discuss with the community.
On Sat, Dec 6, 2014 at 12:28 AM, Carl Steinbach wrote:
> Hi Thejas,
>
> I agree that it's impo
Hi Thejas,
I agree that it's important to give users adequate time to migrate off of
HiveCLI. In order to avoid wasting time what do you think about including
this deprecation notice in the 1.0 release?
On Thu, Dec 4, 2014 at 3:15 PM, Thejas Nair wrote:
> HiveServer, and the original JDBC drive
HiveServer, and the original JDBC driver have already been purged in
trunk. The HiveServer1 docs have been asking users to use HiveServer2
for a long time.
The case with Hive CLI is different. We never marked that as
deprecated or asked users to use beeline instead. Beeline had been
lacking in som
Enis,
What you said about backward compatibility makes sense. Since we are
planning to remove HiveServer1 support, it makes sense to do that in
1.0.
Ending Java 6 support is also something we have been discussing in the
mailing list. We can document Java 7 as minimum requirement for 1.0 .
On Wed,
I'd like to see HiveCLI, HiveServer, and the original JDBC driver
deprecated and purged from the codebase before the 1.0 release. This topic
probably needs its own thread, but I thought I should mention it here.
Thanks.
- Carl
On Wed, Dec 3, 2014 at 2:27 PM, Enis Söztutar wrote:
> Hi,
>
> I am
I think 1.0 release in particular should be a relatively stable release,
since we go from "beta"(?) stage of 0.x to 1.0.
Otherwise, what prevents us from promoting 0.14 to 1.0? 0.14.1 is not done
yet, so it would be great, we will have no 0.x.y releases, and 1.1 will
become the first fix release, n
| Advanced Analytics | Big Data | ECI| EPM | MDM
-Original Message-
From: Enis Söztutar [mailto:e...@apache.org]
Sent: Wednesday, December 03, 2014 5:27 PM
To: dev@hive.apache.org
Subject: Re: Apache Hive 1.0 ?
Hi,
I am the RM for HBase-1.0 coming in a a couple of weeks (hopefully). I
On Wed, Dec 3, 2014 at 2:27 PM, Enis Söztutar wrote:
> Hi,
>
> I am the RM for HBase-1.0 coming in a a couple of weeks (hopefully). I
> think both HBase and Hive are past due for doing 1.0 releases. So I am a
> major +1 for Hive-1.0 (non-binding of course).
>
Agreed :)
>
> The important thing f
Hi,
I am the RM for HBase-1.0 coming in a a couple of weeks (hopefully). I
think both HBase and Hive are past due for doing 1.0 releases. So I am a
major +1 for Hive-1.0 (non-binding of course).
The important thing for calling something 1.0 I think is the focus on user
level API and compatibility
Would everyone just laugh if I suggested that a 1.0 release ought to
include complete documentation?
-- Lefty
On Tue, Dec 2, 2014 at 9:32 PM, Thejas Nair wrote:
> The reasons for confusion in the Hadoop case were different. There
> were many branches, and new features were added in minor versi
The reasons for confusion in the Hadoop case were different. There
were many branches, and new features were added in minor version
releases, eg kerberos security was not there in "0.20.2", but it was
added in "0.20.20x". Then you had other versions like "0.21", but the
older "0.20.20x" version wa
Major release means more functionality, while minor releases provides
stability. Therefore, I'd think, 1.0, as a major release, should bring in
something new to the user. If it's desirable to provide more stable
release, then 0.14.1, 0.14.2, and so on are the right ones. In my opinion,
we should av
I think it's better to do 1.0 release off a maintenance release, since that
is more stable. Trunk is moving fast.
HBase uses odd release numbers for this purpose, where 0.95, 97, 99 etc.
are dev releases and 0.96, 0.98, 1.0 etc. are public; that works well for
baking, but since we don't have that s
Hi Thejas,
Thank you very much for your proposal!
Hadoop did something similar renaming branches to branch-1 and
branch-2. At the time, although I was very much in favor of the new
release numbers, I thought it could have been handled better. Renaming
release branches ended up being very confusin
17 matches
Mail list logo
