Hi Mariana,
You could try defining an array of whatever type you need.
See https://phoenix.apache.org/array_type.html for more details.
- Josh
Mariana Medeiros wrote:
Hello :)
I have a Java class Example with a String and an ArrayList fields.
I am using Apache phoenix to insert and read
Hi Naveen,
The Protocol Buffer dependency on 2.5 is very unlikely to change in
Phoenix as that is directly inherited from HBase (as you can imagine,
these need to be kept in sync).
There are efforts, in both HBase and Phoenix, underway to provide
shaded-jars for each project which would
"statementId": 20,
"sql": "SELECT * FROM us_population",
"maxRowCount": -1
}
And this is the commit command response (if it can give you more
insights)
{
"response": "resultSet",
"connectionId": "8",
"state
Nope, you shouldn't need to do this.
"statements" that you create using the CreateStatementRequest are very
similarly treated to the JDBC Statement interface (they essentially
refer to an instance of a PhoenixStatement inside PQS, actually).
You should be able to create one statement and
Also, you're using the wrong command.
You want "prepareAndExecute" not "prepareAndExecuteBatch".
Josh Elser wrote:
Thanks, will fix this.
Plamen Paskov wrote:
Ah i found the error. It should be "sqlCommands": instead of
"sqlCommands",
The documentati
; ]
}
And this is the response i receive:
Error 500
HTTP ERROR: 500
Problem accessing /. Reason:
com.fasterxml.jackson.core.JsonParseException: Unexpected
character (',' (code 44)): was expecting a colon to separate field
name and value
at [Source: java.io.StringReader@41709697; line: 5,
", "UPSERT INTO
us_population(STATE,CITY,POPULATION) VALUES('C2','City 2',100)" ]
}
And this is the response i receive:
Error 500
HTTP ERROR: 500
Problem accessing /. Reason:
com.fasterxml.jackson.core.JsonParseException: Unexpected
character (',' (code 44)): was ex
What version of Phoenix are you using?
Plamen Paskov wrote:
Hey folks,
I'm trying to UPSERT some data via the json api but no luck for now. My
requests looks like:
{
"request": "openConnection",
"connectionId": "6"
}
{
"request": "createStatement",
"connectionId": "6"
}
{
"request":
For reference materials: definitely check out
https://calcite.apache.org/avatica/
While JSON is easy to get started with, there are zero guarantees on
compatibility between versions. If you use protobuf, we should be able
to hide all schema drift from you as a client (e.g. applications you
(-cc dev@phoenix)
Deepak,
As the name suggests, that release is targeted for HBase-0.98.x release
lines. Any compatibility of an older release of HBase than 0.98 is
likely circumstantial.
I can't speak on behalf of the HBase community, but I feel relatively
confident in suggesting that it
Hi Jared,
This is just a bad error message on PQS' part. Sorry about that. IIRC,
it was something obtuse like not finding the server-endpoint for the
JSON message you sent.
If you want to do a POST and use the body, you can just put the bytes
for your JSON blob in there and that should be
If you invoked a commit on PQS, it should have flushed any cached values
to HBase. The general messages you described in your initial post look
correct at a glance.
If you have an end-to-end example of this that I can play with, I can
help explain what's happening inside of PQS. If you want
Hi Pierre,
1.1.2.2.4 is not a version of Apache HBase. Might you be needing to
contact a vendor for specific information?
Either way, the phoenix shaded client and server (targeted for HBase
server) are not attached to the Maven build which means that they are
not deployed via Maven as a
Let's think back to before transactions where added to Phoenix.
With autoCommit=false, updates to HBase will be batched in the Phoenix
driver, eventually flushing on their own or whenever you invoked
commit() on the connection.
With autoCommit=true, updates to HBase are flushed with every
Hi Jared,
Sounds like https://issues.apache.org/jira/browse/CALCITE-780
That version of Phoenix (probably) is using Calcite-1.2.0-incubating.
You could ask the vendor to update to a newer version, or use Phoenix
4.7.0 (directly from Apache) which is using Calcite-1.6.0.
Jared Katz wrote:
Also, setting -Dsun.security.krb5.debug=true when you launch your Java
application will give you lots of very helpful information about what is
happening "under the hood".
Sanooj Padmakumar wrote:
Thanks Josh and everyone else .. Shall try this suggestion
On 22 Mar 2016 09:36, &
Correct, James:
Phoenix-4.7.0 uses Calcite-1.6.0. This included lots of goodies includes
commit/rollback support. Phoenix-4.6.0 used Calcite-1.3.0. In general,
if you want to use the QueryServer, I'd strongly recommend trying to go
with Phoenix-4.7.0. You'll inherit *lots* of
Yeah, I don't think the inclusion of Python code should be viewed as a
barrier to inclusion (maybe just a hurdle). I've seen other projects
(Ambari, iirc) which have tons of Python code and lots of integration.
The serialization for PQS can be changed via a single configuration
property in
I only wired up commit/rollback in Calcite/Avatica in Calcite-1.6.0 [1],
so I Phoenix-4.6 isn't going to have that in the binaries that you can
download (Phoenix-4.6 is using 1.3.0-incubating). This should be
included in the upcoming Phoenix-4.7.0.
Sadly, I'm not sure why autoCommit=true
Hi Steve,
Sorry for the delayed response.
Putting the "payload" (json or protobuf) into the POST instead of the
header should be the 'recommended' way forward to avoid the limit as you
ran into [1]. I think Phoenix >=4.6 was using Calcite-1.4, but my memory
might be failing me.
Regarding
Ns G wrote:
Hi All,
I have written a simple class to access phoenix.
I am able to establish connection. But when executing below line i get
the error.
conn = DriverManager.getConnection(dbUrl);
I am facing below exception when accessing phoenix through JDBC from
eclipse.
INFO - Call
301 - 321 of 321 matches
Mail list logo
