[jira] [Commented] (PHOENIX-6665) PreparedStatement#getMetaData() fails on parametrized "select next ? values for SEQ"
[
https://issues.apache.org/jira/browse/PHOENIX-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509609#comment-17509609
]
ASF GitHub Bot commented on PHOENIX-6665:
-
stoty opened a new pull request #1406:
URL: https://github.com/apache/phoenix/pull/1406
…elect next ? values for SEQ"
--
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
> PreparedStatement#getMetaData() fails on parametrized "select next ? values
> for SEQ"
> -
>
> Key: PHOENIX-6665
> URL: https://issues.apache.org/jira/browse/PHOENIX-6665
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.0
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Major
>
>
> {code:java}
> PreparedStatement nextStmt = conn.prepareStatement("SELECT NEXT ? VALUES FOR
> SEQ_TABLE");
> nextStmt.getMetaData();{code}
> Fails.
> According to the PreparedStatement javadoc, this should work:
> {quote}
> Because a {{PreparedStatement}} object is precompiled, it is possible to know
> about the {{ResultSet}} object that it will return without having to execute
> it. Consequently, it is possible to invoke the method {{getMetaData}} on a
> {{PreparedStatement}} object rather than waiting to execute it and then
> invoking the {{ResultSet.getMetaData}} method on the {{ResultSet}} object
> that is returned.
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (PHOENIX-6671) Avoid ShortCirtuation Coprocessor Connection with HBase 2.x
[ https://issues.apache.org/jira/browse/PHOENIX-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509610#comment-17509610 ] Lars Hofhansl commented on PHOENIX-6671: Cool. Thanks for checking! I'd vote to get it in then. We can always revert to the old behavior if/when this is fixed in HBase (and we dropped support for or discourage any version of HBase that has this bug.) > Avoid ShortCirtuation Coprocessor Connection with HBase 2.x > --- > > Key: PHOENIX-6671 > URL: https://issues.apache.org/jira/browse/PHOENIX-6671 > Project: Phoenix > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Major > Fix For: 5.2.0, 5.1.3 > > Attachments: 6671-5.1.txt > > > See PHOENIX-6501, PHOENIX-6458, and HBASE-26812. > HBase's ShortCircuit Connection are fundamentally broken in HBase 2. We might > be able to fix it there, but with all the work the RPC handlers perform now > (closing scanning, resolving current user, etc), I doubt we'll get that 100% > right. HBase 3 has removed this functionality. > Even with HBase 2, which does not have the async protobuf code, I could > hardly see any performance improvement from circumventing the RPC stack in > case the target of a Get or Scan is local. Even in the most ideal conditions > where everything is local, there was improvement outside of noise. > I suggest we do not use ShortCircuited Connections in Phoenix 5+. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [phoenix] stoty opened a new pull request #1406: PHOENIX-6665 PreparedStatement#getMetaData() fails on parametrized "s…
stoty opened a new pull request #1406: URL: https://github.com/apache/phoenix/pull/1406 …elect next ? values for SEQ" -- 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
