Andrew Purtell wrote:
This is because the Accumulo shell is a custom built shell? If so, we had
one of those once and replaced it with the IRB based one. We didn't settle
on JRuby right away but, at the time, the consensus was we didn't want to
be in the business of maintaining yet another REPL
That's only if you assume HBase users actually understand Ruby though, no?
Yes, and this is a fair point.
The language REPL in which we're embedding the shell DSL doesn't have to be
Ruby. JavaScript would work, maybe via Nashorn. Python would work, via
Jython. Or Scala's REPL, even.
On Wed,
Only shell we could
swap in w/o annoying users would be SQL (ducks);
[...]
You would
also have to manage expectations: i.e. that the SQL would be extremely
basic and that the REPL does not come with an idling 100 node cluster
ready to take up any involved queries.
If we are
If you were going to replace Ruby, Python (Jython) and Scala would make more
sense.
Then you could go to play (the Scala GUI) for a GUI to HBase reusing the code.
On May 13, 2015, at 3:38 PM, Andrew Purtell apurt...@apache.org wrote:
That's only if you assume HBase users actually
I'm also in favor of a rewrite in another language (but it doesn't have to
be now). This is very subjective but I never got the hang of the Ruby
stuff, it's always annoying to use and I end up googling Ruby stuff almost
every time I want to do something that's not covered in the help command.
On Wed, May 13, 2015 at 1:38 PM, Andrew Purtell apurt...@apache.org wrote:
That's only if you assume HBase users actually understand Ruby though,
no?
Yes, and this is a fair point.
The language REPL in which we're embedding the shell DSL doesn't have to be
Ruby. JavaScript would work,
Hi folks!
If you weren't aware, our current shell relies on Ruby, specifically the
REPL program IRB from JRuby. When we launched 1.0 we were on JRuby 1.6 with
defaults, which means we're stuck on Ruby 1.8.
For those that don't already know, Ruby 1.8 is super old and has been
walking off into the
So…
Silly question…
Do you really need to worry about backward’s compatibility?
How many people have customized HBaseShell ?
What are the common customizations and if you port HBase shell, how much work
would filter through to the custom code?
On May 13, 2015, at 11:22 AM, Sean Busbey
Nice writeup Sean.
Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license is
still amenable and hopefully jruby 9k will be slimmer than jruby 1.7+.
But if we are going to do a significant shell refactor for hbase 2.0,
should we consider doing something more radical; e.g. a new
I'd be curious to hear proposals for a new shell. Wondering what the
arguments in favor would be and arguments against current.
JRuby has served us well. Recently it personally saved me hassle by
allowing scripted surgery (advanced ops) rather than dev of a one off Java
utility. OTOH, if what we
I would love to rip out the JRuby shell entirely and make something closer
to the Accumulo shell, but I expect that will
1) be way more work
2) be even less compatible for those that rely on customizations.
I figured given time we could get a preview user shell (rather than
power shell via irb)
On May 13, 2015 12:06 PM, Michael Segel michael_se...@hotmail.com wrote:
So…
Silly question…
Do you really need to worry about backward’s compatibility?
How many people have customized HBaseShell ?
What are the common customizations and if you port HBase shell, how much
work would filter
sorry to say I don't good at Ruby .
HBase Shell may should upgrade :)
2015-05-14 1:06 GMT+08:00 Michael Segel michael_se...@hotmail.com:
So…
Silly question…
Do you really need to worry about backward’s compatibility?
How many people have customized HBaseShell ?
What are the common
Why is the Accumulo shell superior?
Is it scriptable?
On Wed, May 13, 2015 at 10:28 AM, Sean Busbey bus...@cloudera.com wrote:
I would love to rip out the JRuby shell entirely and make something closer
to the Accumulo shell, but I expect that will
1) be way more work
2) be even less
Pros:
* It's easier to test and maintain
* it's easier to script with
* its interactive mode feels mode focused on the task of interacting with
a cluster to me (maybe this is just acting like a psql or mysql shell)
Cons
* adding custom commands requires knowing java
--
Sean
On May 13, 2015
Agreed on these points, Sean. Having used both, I think both approaches
have their value and their drawbacks.
The ruby shell is _wonderful_ from having a full programming language to
interact with. Accumulo's shell would force you to use your standard
unix-toolbelt if you want to do any extra
Having two shells - a simple user shell for tinkering and an advanced one
for real ops and developers - would be fine, as long as one is not
deprecated. Can't trust something deprecated for tooling.
On Wed, May 13, 2015 at 10:52 AM, Esteban Gutierrez este...@cloudera.com
wrote:
+1 for new
+1 for new JRuby for now and having a JIRA to discuss what features should
this shell have would be great.
However, I think that during the last few years many of us have used the
hbase shell for major surgery as Andrew said and it has added some
confusion to users about what the hbase shell is
This is because the Accumulo shell is a custom built shell? If so, we had
one of those once and replaced it with the IRB based one. We didn't settle
on JRuby right away but, at the time, the consensus was we didn't want to
be in the business of maintaining yet another REPL when specialist open
Hmmm.
So if we move to a different tech, the modifications / customizations people
have done are going to be useless.
If we upgrade to a new version of JRuby, some scripts may not have issues,
others may have some , and a third group would have major rewrites.
The interesting / downside to
20 matches
Mail list logo
