Hi,
Thanks for reproducer.
I've make some changes and run test against 2.1, 2.2 and 2.3 version.
Test with affinity key fails on 2.1 and 2.2 versions and looks ok on 2.3
version.
Seems, there was a bug in 2.1 and it is already fixed in 2.3.
PFA repro.
On Thu, Oct 26, 2017 at 10:39 AM, iostream
One more thing to add - when I remove "affinityKey" from ID, I am able to
query successfully. The error occurs when I set "ID" as my affinityKey. Is
it a known bug?
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Reproducer code-
ResultSet rs = null;
try {
Class.forName("org.apache.ignite.IgniteJdbcThinDriver");
Connection conn = DriverManager
.getConnection("jdbc:ignite:thin://127.0.0.1/");
Hi,
Looks like a bug.
Can you share a simple repro?
So, it can be easily checked against master or ignite-2.3 branch if it is
already fixed or a ticket should be created.
On Wed, Oct 25, 2017 at 5:28 PM, iostream wrote:
> I think i have found the problem here. When I
I think i have found the problem here. When I query my cache on the PRIMARY
KEY, the query throws exception. When I removed PRIMARY KEY from "id", query
is working fine. How do I query on the PRIMARY KEY ?
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi Andrew,
I created a table with BIGINT instead of LONG data type in cache. I am still
getting the same error when I try to query using java.Lang.Long
DDL-
CREATE TABLE test4
(
id /BIGINT/,
name VARCHAR,
PRIMARY KEY (id)
)
WITH "backups=1,affinityKey=id";
--
Hi,
Got it.
Ignite has H2 in underneath. Try to use BIGINT as it should be mappe to
java Long type.
On Tue, Oct 24, 2017 at 9:54 PM, iostream wrote:
> Hi Andrew,
>
> The result set was /null/ because the query failed in ignite. This is the
> only stack trace printed.
>
>
Hi Andrew,
The result set was /null/ because the query failed in ignite. This is the
only stack trace printed.
The problem occurs only when I query on LONG column "id". When I query on
VARCHAR column "name" (/eg. select * from test where name = "abc"/), I am
able to get the result set.
What
Hi,
Looks like stacktrace is incomplete and it doesn't contains any reason
why JdbcResponse
has 'null' res field.
Please, if connection string is correct (by default 10800 port should be
used) and share full logs.
Also, it is possible you close connection before results be retrieved from