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
