[
https://issues.apache.org/jira/browse/PHOENIX-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17419533#comment-17419533
]
ASF GitHub Bot commented on PHOENIX-6523:
-----------------------------------------
ramatronics commented on a change in pull request #1280:
URL: https://github.com/apache/phoenix/pull/1280#discussion_r715281233
##########
File path:
phoenix-core/src/main/java/org/apache/phoenix/jdbc/bootstrapz/HRpcHBaseRegistryBootstrap.java
##########
@@ -0,0 +1,44 @@
+package org.apache.phoenix.jdbc.bootstrapz;
Review comment:
> The current stateless solution is not worth it.
> you should encapsulate your code and data in a class.
I guess I'm failing to see the opportunity here for encapsulating the
code/data. My original intent was to abstract the interface for
`generateConnectionProps` and the logic each registry has for it. Doesn't
necessarily mean we have to feed it some data to abstract as well. Sure maybe
down the road, it may make sense to move more data from `PhoenixEmbeddedDriver`
into these registry classes as per need... but I don't think any of these
classes require context from the URL after being created for the current use
case.
> relies on the fact the state for the ZK and HRpp connections are named
similarly
How? Was hoping to rely on the fact that unique ZK and HRpc identifiers can
be parsed into a discrete set of enums. They essentially provide translation of
the string value from the conn string to an enum which we then parse into the
actual class of the registry. We can eliminate the enum and just add straight
string comparisons, but regardless we need to check the protocol string
specified in the connection URL.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@phoenix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Support for HBase Registry Implementations through Phoenix connection URL
> -------------------------------------------------------------------------
>
> Key: PHOENIX-6523
> URL: https://issues.apache.org/jira/browse/PHOENIX-6523
> Project: Phoenix
> Issue Type: Improvement
> Components: core
> Reporter: Ramie Raufdeen
> Priority: Major
>
> https://issues.apache.org/jira/browse/HBASE-23305
> https://issues.apache.org/jira/browse/HBASE-18095
>
> HBase now supports a zookeeper-less connection strategy using a Master
> Registry implementation.
>
> For this to work, the client simply needs to set a list of <host:port>s of
> the HMaster quorum
>
> {code:java}
> <property>
> <name>hbase.masters</name>
> <value>master1:16000,master2:16001,master3:16000</value>
> </property>
> {code}
>
> To support opting into this from a Phoenix connection URL, we can introduce a
> "connector type". We'll leverage the *+* char of [JDBC URL
> grammar|https://docs.oracle.com/cd/E17952_01/connector-j-8.0-en/connector-j-reference-jdbc-url-format.html]
> to specify the connection type. Connections will start to look something
> like this:
> {code:java}
> jdbc:phoenix+zk:hostname1,2,3...:<properties>
> jdbc:phoenix+hrpc:hostname1,2,3...:<properties>
> jdbc:phoenix+bigtable:hostname1,2,3...:<properties>{code}
> Above are examples of opting into hrpc/zk/bigtable registry implementations
> of HBase.
>
> If no connector is specified, the driver will default to a Zookeeper based
> connection.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
