[jira] [Moved] (CALCITE-1081) Need Detailed Documentation for HTTP Avatica Support
[
https://issues.apache.org/jira/browse/CALCITE-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser moved PHOENIX-2660 to CALCITE-1081:
--
Affects Version/s: (was: 4.7.0)
(was: 4.6.0)
Workflow: jira (was: no-reopen-closed, patch-avail)
Key: CALCITE-1081 (was: PHOENIX-2660)
Project: Calcite (was: Phoenix)
> Need Detailed Documentation for HTTP Avatica Support
>
>
> Key: CALCITE-1081
> URL: https://issues.apache.org/jira/browse/CALCITE-1081
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Steve T
>
> I was unable to find any documentation on how to use the Avatica features. I
> was not even able to find them on the Avatica site. Would be great if
> Phoenix had a least a few examples of how to us the feature such as the one I
> wrote below. It took me 2-3 days to figure it out with the help of
> u...@phoenix.apache.org . Should have only taken about 15 minutes. Granted,
> the JSON format is outdated in recent versions, but you get the idea. I
> couldn't even figure out which requests were required and what sequence they
> had to be in.
> {code:title=example_upsert.sh|borderStyle=solid}
> #!/bin/bash
> curl -XPOST -H 'Content-Type application/json; charset=UTF-8' -d
> '{"connectionId": "----", "request":
> "openConnection"}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": null, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": true, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"createStatement\",\"connectionId\":\"----\"}"
> http://10.0.100.28:8765/
> echo
> echo Enter the statementId:
> read statement_id
> echo
> echo Enter the value:
> read value
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL2',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"closeStatement\",\"connectionId\":\"----\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "closeConnection"}' http://10.0.100.28:8765/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CALCITE-1081) Need Detailed Documentation for HTTP Avatica Support
[
https://issues.apache.org/jira/browse/CALCITE-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-1081:
---
Assignee: Josh Elser
> Need Detailed Documentation for HTTP Avatica Support
>
>
> Key: CALCITE-1081
> URL: https://issues.apache.org/jira/browse/CALCITE-1081
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Steve T
>Assignee: Josh Elser
>
> I was unable to find any documentation on how to use the Avatica features. I
> was not even able to find them on the Avatica site. Would be great if
> Phoenix had a least a few examples of how to us the feature such as the one I
> wrote below. It took me 2-3 days to figure it out with the help of
> u...@phoenix.apache.org . Should have only taken about 15 minutes. Granted,
> the JSON format is outdated in recent versions, but you get the idea. I
> couldn't even figure out which requests were required and what sequence they
> had to be in.
> {code:title=example_upsert.sh|borderStyle=solid}
> #!/bin/bash
> curl -XPOST -H 'Content-Type application/json; charset=UTF-8' -d
> '{"connectionId": "----", "request":
> "openConnection"}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": null, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": true, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"createStatement\",\"connectionId\":\"----\"}"
> http://10.0.100.28:8765/
> echo
> echo Enter the statementId:
> read statement_id
> echo
> echo Enter the value:
> read value
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL2',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"closeStatement\",\"connectionId\":\"----\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "closeConnection"}' http://10.0.100.28:8765/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139433#comment-15139433 ] Julian Hyde commented on CALCITE-1062: -- I took a quick look, looks good. I'm going to test it and do some fix up (I think we should have a SqlKind value for ROW_NUMBER, and I'd like to convert the various filterOperatorXxx methods to use Iterators.filter) but I think your PR is sound. > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Moved] (CALCITE-1082) CORS Support for Avatica Requests on Phoenix Query Server
[
https://issues.apache.org/jira/browse/CALCITE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser moved PHOENIX-2661 to CALCITE-1082:
--
Affects Version/s: (was: 4.7.0)
(was: 4.6.0)
Workflow: jira (was: no-reopen-closed, patch-avail)
Key: CALCITE-1082 (was: PHOENIX-2661)
Project: Calcite (was: Phoenix)
> CORS Support for Avatica Requests on Phoenix Query Server
> -
>
> Key: CALCITE-1082
> URL: https://issues.apache.org/jira/browse/CALCITE-1082
> Project: Calcite
> Issue Type: New Feature
>Reporter: Steve T
>Priority: Minor
>
> It would be super cool if I could write Javascript in a web page to
> read/write my Phoenix tables. I spend the last few days learning about CORS
> and browser security. I found out that what I am trying to accomplish cannot
> be readily done because the browser adds CORS headers (like
> {color:blue}{{Origin: }}{color}) and methods (like
> {color:blue}{{method: OPTIONS}}{color}) that are not supported by Phoenix
> Query Server.
> I do not know if this can be added on the Phoenix side or if it has to be
> added on the Avatica side, but for the time being I am trying the following
> to make it work:
> 1. Unconventional Javascript to remove the
> {color:blue}{{X-Requested-With}}{color} header in the request.
> 2. One line code change in Avatica's
> {color:blue}{{AvaticaJsonHandler.handle()}}{color} to add an
> {color:blue}{{Access-Control-Allow-Origin: *}}{color} header to the response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CALCITE-1082) CORS Support for Avatica Requests
[
https://issues.apache.org/jira/browse/CALCITE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-1082:
Summary: CORS Support for Avatica Requests (was: CORS Support for Avatica
Requests on Phoenix Query Server)
> CORS Support for Avatica Requests
> -
>
> Key: CALCITE-1082
> URL: https://issues.apache.org/jira/browse/CALCITE-1082
> Project: Calcite
> Issue Type: New Feature
>Reporter: Steve T
>Priority: Minor
>
> It would be super cool if I could write Javascript in a web page to
> read/write my Phoenix tables. I spend the last few days learning about CORS
> and browser security. I found out that what I am trying to accomplish cannot
> be readily done because the browser adds CORS headers (like
> {color:blue}{{Origin: }}{color}) and methods (like
> {color:blue}{{method: OPTIONS}}{color}) that are not supported by Phoenix
> Query Server.
> I do not know if this can be added on the Phoenix side or if it has to be
> added on the Avatica side, but for the time being I am trying the following
> to make it work:
> 1. Unconventional Javascript to remove the
> {color:blue}{{X-Requested-With}}{color} header in the request.
> 2. One line code change in Avatica's
> {color:blue}{{AvaticaJsonHandler.handle()}}{color} to add an
> {color:blue}{{Access-Control-Allow-Origin: *}}{color} header to the response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139920#comment-15139920 ] Julian Hyde commented on CALCITE-1062: -- Ah, I found it. The stack got deeper because SqlOperator.deriveType no longer calls deriveType on each operand. It is a bit more work to call deriveType early, but keeps the stack smaller, so I restored it. I also discovered CALCITE-1083, which was causing an O(n ^ 2) slow-down (but not affecting stack-size). > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1082) CORS Support for Avatica Requests
[
https://issues.apache.org/jira/browse/CALCITE-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139414#comment-15139414
]
Josh Elser commented on CALCITE-1082:
-
Moved this one too, [~brane2]. I've run into CORS before, I'm a little fuzzy.
Have you thought about the security implications of this? If we would set the
header, are there other things we'd have to worry about (in other words, do we
need an option to turn this on/off per user)?
> CORS Support for Avatica Requests
> -
>
> Key: CALCITE-1082
> URL: https://issues.apache.org/jira/browse/CALCITE-1082
> Project: Calcite
> Issue Type: New Feature
> Components: avatica
>Reporter: Steve T
>Priority: Minor
>
> It would be super cool if I could write Javascript in a web page to
> read/write my Phoenix tables. I spend the last few days learning about CORS
> and browser security. I found out that what I am trying to accomplish cannot
> be readily done because the browser adds CORS headers (like
> {color:blue}{{Origin: }}{color}) and methods (like
> {color:blue}{{method: OPTIONS}}{color}) that are not supported by Phoenix
> Query Server.
> I do not know if this can be added on the Phoenix side or if it has to be
> added on the Avatica side, but for the time being I am trying the following
> to make it work:
> 1. Unconventional Javascript to remove the
> {color:blue}{{X-Requested-With}}{color} header in the request.
> 2. One line code change in Avatica's
> {color:blue}{{AvaticaJsonHandler.handle()}}{color} to add an
> {color:blue}{{Access-Control-Allow-Origin: *}}{color} header to the response.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CALCITE-623) Use Jenkins
[ https://issues.apache.org/jira/browse/CALCITE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde reassigned CALCITE-623: --- Assignee: Josh Elser (was: Julian Hyde) > Use Jenkins > --- > > Key: CALCITE-623 > URL: https://issues.apache.org/jira/browse/CALCITE-623 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Josh Elser > > Use Jenkins for continuous integration. > See discussion with [~ndimiduk] and [~mujtabachohan] in CALCITE-553. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1062. -- Resolution: Fixed Fix Version/s: 1.7.0 Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/c1ceba45 and http://git-wip-us.apache.org/repos/asf/calcite/commit/72b2cfb7. Thanks for the PR, [~seanhychu]! > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > Fix For: 1.7.0 > > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Mior updated CALCITE-1080: -- Description: I've started work on an adapter for [Apache Cassandra|https://cassandra.apache.org/]. There's still a fair bit of work to do, but you can successfully issue a fairly broad class of queries with filtering, sorting, and projections pushed down to Cassandra in many cases. Progress can be tracked on [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a brief list of things which still need to be done. I'm hoping this can be useful to others, so it would be good to get a sense of what would be considered complete for future release. *To do* * New tests for test suite (and update [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to support Cassandra) * Allow for partial application of filter predicates (since Cassandra's query language is so limited, this will avoid the case where only trivial predicates can be pushed down) * Allow for partial sorting (for the same reason as above) * Proper quoting of identifiers * Fix projections to avoid projecting unnecessary columns in some circumstances * Proper cost modelling * Exploit native aggregation was: I've started work on an adapter for [Apache Cassandra|https://cassandra.apache.org/]. There's still a fair bit of work to do, but you can successfully issue a fairly broad class of queries with filtering, sorting, and projections pushed down to Cassandra in many cases. Progress can be tracked on [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a brief list of things which still need to be done. I'm hoping this can be useful to others, so it would be good to get a sense of what would be considered complete for future release. *To do* * New tests for test suite (and update [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to support Cassandra) * Allow for partial application of filter predicates (since Cassandra's query language is so limited, this will avoid the case where only trivial predicates can be pushed down) * Allow for partial sorting (for the same reason as above) * Proper quoting of identifiers * Fix projections to avoid projecting unnecessary columns in some circumstances * Proper cost modelling > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140026#comment-15140026 ] Julian Hyde commented on CALCITE-1080: -- [~michaelmior], Fantastic! I have been hoping that someone would do a Cassandra adapter. What can I do to help? I think that adding to calcite-test-dataset is key; it will allow us to start running regular tests, and will allow people to experiment with the adapter. [~vlsi] may be able to help with that. > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CALCITE-623) Use Jenkins
[ https://issues.apache.org/jira/browse/CALCITE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-623. - Resolution: Fixed Fix Version/s: 1.7.0 Fixed, and documented in http://git-wip-us.apache.org/repos/asf/calcite/commit/e0f29dd7 and http://svn.apache.org/viewvc?rev=1729512=rev. > Use Jenkins > --- > > Key: CALCITE-623 > URL: https://issues.apache.org/jira/browse/CALCITE-623 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Josh Elser > Fix For: 1.7.0 > > > Use Jenkins for continuous integration. > See discussion with [~ndimiduk] and [~mujtabachohan] in CALCITE-553. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1062) Allowing SqlOperator to be overridden in validation
[ https://issues.apache.org/jira/browse/CALCITE-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139976#comment-15139976 ] Sean Hsuan-Yi Chu commented on CALCITE-1062: I see. Thanks for helping point out that issue! > Allowing SqlOperator to be overridden in validation > --- > > Key: CALCITE-1062 > URL: https://issues.apache.org/jira/browse/CALCITE-1062 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Sean Hsuan-Yi Chu >Assignee: Sean Hsuan-Yi Chu > > Calcite allows function to be overridden at validation step. To be more > specific, users can provide their SqlOperatorTable, and, at validation step, > their SqlOperatorTable will be called (method: lookupOperatorOverloads) to > get a overriding function. However, so far, SqlOperator (e.g., +, - , *, > etc.) does not have this mechanism yet. > Since other systems (e.g., Apache Drill) would have more flexible type-checks > for SqlOperator's operands, this mechanism is necessary for those systems to > pass through the validation step. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1081) Need Detailed Documentation for HTTP Avatica Support
[
https://issues.apache.org/jira/browse/CALCITE-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140150#comment-15140150
]
Randy Gelhausen commented on CALCITE-1081:
--
[~elserj] please link to these in the phoenix docs. Lack of examples for the
PQS has bitten several users.
> Need Detailed Documentation for HTTP Avatica Support
>
>
> Key: CALCITE-1081
> URL: https://issues.apache.org/jira/browse/CALCITE-1081
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
>Reporter: Steve T
>Assignee: Josh Elser
>
> I was unable to find any documentation on how to use the Avatica features. I
> was not even able to find them on the Avatica site. Would be great if
> Phoenix had a least a few examples of how to us the feature such as the one I
> wrote below. It took me 2-3 days to figure it out with the help of
> u...@phoenix.apache.org . Should have only taken about 15 minutes. Granted,
> the JSON format is outdated in recent versions, but you get the idea. I
> couldn't even figure out which requests were required and what sequence they
> had to be in.
> {code:title=example_upsert.sh|borderStyle=solid}
> #!/bin/bash
> curl -XPOST -H 'Content-Type application/json; charset=UTF-8' -d
> '{"connectionId": "----", "request":
> "openConnection"}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": null, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "connectionSync", "connProps": {"autoCommit": true, "connProps":
> "connPropsImpl", "transactionIsolation": null, "catalog": null, "readOnly":
> null, "dirty": null, "schema": null}}' http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"createStatement\",\"connectionId\":\"----\"}"
> http://10.0.100.28:8765/
> echo
> echo Enter the statementId:
> read statement_id
> echo
> echo Enter the value:
> read value
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"prepareAndExecute\",\"connectionId\":\"----\",\"sql\":\"upsert
> into CAT_MAP(CHA, CAT, MAP) values('TEST_RECORD_CHANNEL2',
> 'Test::Record::Channel::Category', '$value')\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d
> "{\"request\":\"closeStatement\",\"connectionId\":\"----\",
> \"statementId\":$statement_id}" http://10.0.100.28:8765/
> curl -XPOST -d '{"connectionId": "----",
> "request": "closeConnection"}' http://10.0.100.28:8765/
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140033#comment-15140033 ] Julian Hyde commented on CALCITE-1080: -- Ah, I see you've already made a couple of PRs to [~vlsi]. https://github.com/vlsi/calcite-test-dataset/pull/3 > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-1080) Cassandra adapter
[ https://issues.apache.org/jira/browse/CALCITE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140248#comment-15140248 ] Michael Mior commented on CALCITE-1080: --- In terms of help, I wouldn't mind some code review of what I have so far to see if the approach I'm taking makes sense. In the mean time, I think I'll focus on getting a good set of tests going since I agree it would make it easier for others to start playing with it. > Cassandra adapter > - > > Key: CALCITE-1080 > URL: https://issues.apache.org/jira/browse/CALCITE-1080 > Project: Calcite > Issue Type: New Feature >Reporter: Michael Mior >Assignee: Julian Hyde > > I've started work on an adapter for [Apache > Cassandra|https://cassandra.apache.org/]. > There's still a fair bit of work to do, but you can successfully issue a > fairly broad class of queries with filtering, sorting, and projections pushed > down to Cassandra in many cases. > Progress can be tracked on > [GitHub|https://github.com/michaelmior/calcite/tree/cassandra]. Below is a > brief list of things which still need to be done. I'm hoping this can be > useful to others, so it would be good to get a sense of what would be > considered complete for future release. > *To do* > * New tests for test suite (and update > [calcite-test-dataset|https://github.com/vlsi/calcite-test-dataset] to > support Cassandra) > * Allow for partial application of filter predicates (since Cassandra's query > language is so limited, this will avoid the case where only trivial > predicates can be pushed down) > * Allow for partial sorting (for the same reason as above) > * Proper quoting of identifiers > * Fix projections to avoid projecting unnecessary columns in some > circumstances > * Proper cost modelling > * Exploit native aggregation -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CALCITE-553) "mvn clean install" fails due to missing SqlParserImpl
[
https://issues.apache.org/jira/browse/CALCITE-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15140408#comment-15140408
]
Josh Elser commented on CALCITE-553:
I think this is ultimately boiling down to the profile activation check
happening before the clean phase runs. The profile isn't activated because
core/target/generated-sources/fmpp/javacc/Parser.jj exists, the clean destroys
all of target, fmpp doesn't get re-run, and then the javacc plugin also skips
itself because its source directory (the fmpp output) doesn't exist.
I can understand the worth in trying to get incremental compliation and faster
builds, but it really bothers me when it comes at the cost of breaking the
expected semantics of the build tool. I'll see if there's some kind of trick I
can find to work around this, but, if I can't figure something out, I'm going
to suggest we remove the activation block (and run it all the time).
> "mvn clean install" fails due to missing SqlParserImpl
> --
>
> Key: CALCITE-553
> URL: https://issues.apache.org/jira/browse/CALCITE-553
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Vladimir Sitnikov
>
> Every second time I call {mvn -DskipTests clean install} it fails with
> {code}[ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[24,42]
> cannot find symbol
> symbol: class SqlParserImpl
> location: package org.apache.calcite.sql.parser.impl
> [ERROR]
> /home/jhyde/open1/calcite.2/core/src/main/java/org/apache/calcite/sql/parser/SqlParser.java:[201,50]
> cannot find symbol
> symbol: variable SqlParserImpl
> location: class org.apache.calcite.sql.parser.SqlParser.ConfigBuilder
> [INFO] 2 errors{code}
> I think CALCITE-484 broke something; maybe the parser is not generated
> correctly if at the start of the mvn command (before clean) the parser
> already exists.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
