Thanks James.
This means that If I don't want to delete my data, I can alter the table
and replicate the TIMESTAMP column to a new UNSIGNED_TIMSTAMP column?
On Mon, Dec 21, 2015 at 10:29 PM, James Taylor
wrote:
> Use UNSIGNED_TIMESTAMP instead.
>
> On Mon, Dec 21, 2015 at 12:17
Hello,
I'm using Phoenix 4.3.0 in CDH5.4 cluster.
I'm trying to parse a TIMESTAMP column from a table using HBase native
API. (Because I want to get all versions of that column, which I
couldn't do using Phoenix JDBC)
>From the documentation, the TIMESTAMP type is a 12-byte value, 8-byte
for the m
Hello,
I am using Phoenix 4.3.0 on CDH5.4 Cluster.
I have a daily batch process that upserts values to an entire Pheonix table
(there are no new records in each run, only updated values to all columns
on each row).
We have noticed that after 10-20 full runs, SELECT queries that contains
WHERE clau
Hello,
I am using Phoenix 4.3.0 on CDH5.4 Cluster.
I have a daily batch process that upserts values to an entire Pheonix table
(there are no new records in each run, only updated values to all columns
on each row).
We have noticed that after 10-20 full runs, SELECT queries that contains
WHERE clau
run netstat -a 1 | grep "SYN_SENT" and check if port 2181 is blocked in
your network..
On Sat, Oct 31, 2015 at 8:00 PM, Steve Terrell
wrote:
> OK, did some more troubleshooting. Still can't run sqlline.py from my
> macbook laptop. Still hangs.
>
> My HBase cluster is an Amazon EMR, and I can r
Are you using sqlline via putty?
If so, consider stretching it's window wider so the whole description would
fit in (and stretch it before running sqlline)
Also, consider using SQuireL client for better view of your data...
Regards,
David
בתאריך 3 בספט׳ 2015 16:21, "James Heather"
כתב:
> Eek.
r local time zone. A case could certainly be
> made for aligning the ResultSet.getString for Timestamps to return the same
> thing as Timestamp.toString(), although in some ways it's also handy to be
> able to view Timestamps as they are really stored in Phoenix.
>
> - Gabriel
>
&g
n the JDBC spec that is causing the issue, but I need to nail down
your exact use case to verify this.
- Gabriel
On Sun, Aug 16, 2015 at 5:54 PM, Naor David wrote:
> I'm upserting timestamps by setting a java.sql.TimeStamp object to it's
> proper index in my PreparedStatement objec
ones, so the best way to resolve
> this issue is probably for you to post some examples of the statements
> you're running, what output you're getting, and what you would expect
> instead of what you're getting.
>
> - Gabriel
>
> 1. http://phoenix.apache.or
Hello,
I recently installed Apache Pheonix 4.3 at a Cloudera cluster via parcel
installation.
My problem is that while inserting a java.sql.TimeStamp object via jdbc,
the corresponding inserted timestamp column is converted to GMT+0 timezone.
(While my local time is GMT+3).
I understood that one ca
10 matches
Mail list logo
