Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <eb4706e0803202211v4bd83b3ase2244b0a5d32794@mail.gmail.com>
Date: Fri, 21 Mar 2008 14:11:05 +0900
From: "edward yoon" <edward@udanax.org>
To: hbase-dev@hadoop.apache.org
Subject: Re: [VOTE] Release hbase 0.1.0 (Candidate 0)
In-Reply-To: <47E33E67.5070806@duboce.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47E27ED5.7080300@duboce.net>
	 <eb4706e0803201807q118888e6v711c9a2c1a552d16@mail.gmail.com>
	 <a636ef090803201910g223ec468saf426fb472ed2028@mail.gmail.com>
	 <eb4706e0803202016h453f397dgf1fdaa17f66636e@mail.gmail.com>
	 <47E33E67.5070806@duboce.net>

> 1. It is hard to maintain, at least as written.  We keep tripping over
> little bugs that are consuming to fix and its main developer, you, do
> not seem interested in keeping up the basics.  Instead, your efforts
> seem to have been expended working on all forms of facility that plain
> do not belong in HQL or arguing with those who suggest such extensions
> belong elsewhere.

I think this issue is old since last year, and I told you that i won't
expand the hql.
U never got over it.

Just forget.

On 3/21/08, stack <stack@duboce.net> wrote:
> edward yoon wrote:
> > If you considered my advice as below, we could avoid this problem.
> >
>
> That HQL is SQL-like is not its problem; its its advantage.
>
> The main problems with HQL and why it should be removed, IMO, are as
> follows:
>
> 1. It is hard to maintain, at least as written.  We keep tripping over
> little bugs that are consuming to fix and its main developer, you, do
> not seem interested in keeping up the basics.  Instead, your efforts
> seem to have been expended working on all forms of facility that plain
> do not belong in HQL or arguing with those who suggest such extensions
> belong elsewhere.
>
> 2. It is lacking in a few important dimensions.  Operating at a scale is
> one such -- and no, running an MR job from the HQL command-line is not
> the answer (as though clusters have nothing better to do but sit around
> and wait on a users' command-line whim) -- but recent experience trying
> to debug loaded clusters has led me to believe that we need more than
> HQL provides (See 1. for why we can't extend HQL).
>
> Rather than waste more time bringing along the HQL grammer, we should
> just punt on grammar development and instead put up a shell with an
> already debugged grammar for ruby or python or beanshell, etc.,
> preloaded with built-ins that ease the common hbase tasks -- admin,
> basic tests that data inserted properly -- and that allows admins delve
> deeper if necessary.
>
> > I am very sorry about it and political rivalries.
> > I apologize, my team members, for making promises that I couldn't keep.
> >
> No worries.
>
> St.Ack
>


-- 
B. Regards,
Edward yoon @ NHN, corp.