[
https://issues.apache.org/jira/browse/PHOENIX-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481640#comment-14481640
]
Nick Dimiduk commented on PHOENIX-971:
--------------------------------------
Thanks for looking [~gabriel.reid], [~jamestaylor].
bq. the python scripts should probably exit with the status code of the java
command (the other scripts were recently updated to do this as well)
Will do.
bq. I think that the environment variable used for finding the HBase
configuration is typically HBASE_CONF_DIR, and not HBASE_CONF_PATH
HBASE_CONF_PATH is the env var apparently used by Phoenix already. I agree I
think it's incorrect and should be adjusted (I think BigTop uses HBASE_HOME and
HBASE_CONF_DIR). Separate ticket.
bq. I saw that sqlline is a dependency in the driver module, with a TODO about
the bin scripts being the issue. Am I correct in assuming that this can be
fully resolved just within one of the python scripts?
IIRC, we need sqlline as a dependency in order for it to be packaged up into
the uberjar; bin scripts don't know how to access dependencies resolved by
maven. After I made that comment, I was reminded that Phoenix structure looks
pretty different from HBase and Hadoop -- there isn't a lib directory, for
instance. Probably the sqlline dep should be marked as runtime but remaining in
place (so long as it's packaged by the assembly plugin correctly).
bq. maybe the naming of the driver and it's module should include the word
"thin", it might make things a bit more clear in the future
I don't know what JDBC vendors usually do. Maybe [~jamestaylor], [~lhofhansl],
[~apurtell], or [~julianhyde] have experience and opinions in this area.
bq. One question about the URL for the remote driver: What's the typical JDBC
way of differentiating a remote/thin driver from a thick driver ([~julianhyde]
may know)? You've used jdbc:phoenix:remote, but I'm worried that this may not
co-exist with our existing URL
As as Gabriel's question, mostly. I don't have an answer to this question. I
think the IT test has both drivers in its class path and it's able to resolve
the correct one, though I've not looked into is specifically.
bq. Second question (and maybe a dumb one), but do we need a dependency on
jruby for this, as I noticed that in the pom.
You mean the exclusion? No, we don't explicitly use jruby anywhere here. Did I
pull it in unintentionally?
bq. One final question: is the client/server protocol stable, as once this gets
rolled out, changing that will be difficult. Is there a version number embedded
in the protocol? How does it help to maintain b/w compat?
In my opinion, the protocol is still very young. The server right now only
speaks JSON and is not resilient against missing or extraneous methods or
parameters. It's never really been released in a feature-ful way, so it has no
b/w compat story at the moment. A more robust protocol should be coming in the
future. I would recommend Phoenix project make no guarantees about this query
server for a couple releases, give time for Avatica to mature.
> Query server
> ------------
>
> Key: PHOENIX-971
> URL: https://issues.apache.org/jira/browse/PHOENIX-971
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Andrew Purtell
> Assignee: Nick Dimiduk
> Fix For: 5.0.0
>
> Attachments: PHOENIX-971.00.patch, image-2.png
>
>
> Host the JDBC driver in a query server process that can be deployed as a
> middle tier between lighter weight clients and Phoenix+HBase. This would
> serve a similar optional role in Phoenix deployments as the
> [HiveServer2|https://cwiki.apache.org/confluence/display/Hive/Setting+Up+HiveServer2]
> does in Hive deploys.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
