Re: 'Date' and 'Timestamp' types in SQL queries

[Vladimir Ozerov]

There was some changes in how .NET interoperate w/ Java on binary level. No
changes were made to cache or query logic.
I performed a smoke test in Java and observed that Date field was correctly
mapped to H2 date and then vice versa.

Probably this is a kind of configuration problem.

Vladimir.

On Thu, Feb 11, 2016 at 12:41 AM, Dmitriy Setrakyan 
wrote:

> I remember seeing some work done for the .NET support to provide better
> precision for time data values. Could it be that SQL now converts
> everything to Timestamp because of that?
>
> D.
>
> On Wed, Feb 10, 2016 at 10:09 AM, Igor Sapego 
> wrote:
>
> > Hello,
> >
> > Recently I've been working on implementation of the Date and Timestamp
> > types support for C++ client [1] and I today have faced an issue when I
> was
> > running tests with Date and SqlFieldQuery.
> >
> > Here is the issue. I have class that have field of type 'Date'. I was
> able
> > to create
> > instances of that class and put them in a cache, but when I tried to
> > retrieve
> > these fields with SQL query I've got an exception. After the short debug
> > session
> > I have found that the values that SQL queries return are of type
> > 'Timestamp'.
> >
> > So now I'm wonder, is it an expected behavior? Because to me it looks
> like
> > something that may be very confusing for a user. User knows that object's
> > field
> > is of type 'Date' but when they try to call GetNext on query row
> they
> > get an
> > exception.
> >
> > I have also tested simple caches with Date where Date is a value and
> these
> > tests
> > work just fine with 'Date' returned as a result of Cache#Get() requests.
> >
> > [1] - IGNITE-: CPP: Implement Date and Timestamp data types support
> for
> > binary protocol. 
> > Best Regards,
> > Igor
> >
>

Re: MyBatis-Ignite integration release

[Dmitriy Setrakyan]

Thanks Roman, this is awesome news!

Do you know what is the process at MyBatis to move from beta into a final
GA release?

D.

On Wed, Feb 10, 2016 at 11:41 PM, Roman Shtykh  wrote:

> Dear community,
>
> I would like to share the news about MyBatis-Ignite integration release,
> as a result of the collaboration between Ignite and MyBatis teams.
>
> http://blog.mybatis.org/2016/02/mybatis-ignite-released.html
>
> From now please consider using Apache Ignite as your 2nd level MaBatis
> cache.
>
> Best regards,
> Roman
>

[jira] [Created] (IGNITE-2632) "Connection to Ignite Node is not established" is appear unproperly in corner case

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2632:
--

 Summary: "Connection to Ignite Node is not established" is appear 
unproperly in corner case
 Key: IGNITE-2632
 URL: https://issues.apache.org/jira/browse/IGNITE-2632
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Andrey Novikov
Priority: Minor


1) Import model from Demo
2) Open a user's notebook
3) "Connection to Ignite Node is not established" is appear - it is OK
4) Say 1,2,3 and click on Back to configuration
*Observed*: configuration\cluster screen is active but "Connection to Ignite 
Node is not established" is appear too.

*Expected*: no the second "Connection to Ignite Node is not established" should 
appear on the screen



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Compiling Ignite against different JDKs

[Dood]

Hello all,

I am working on a ticket that is not very difficult, if you are good 
with Idea, Java, Maven etc. I have been a developer in various languages 
but new to Java ;).


I had JDK8 installed and I introduced some changes to the code base that 
cause it to not compile (apparently) against the JDK7. I downloaded JDK7 
and installed it, I went into Project Structure->JDKs in Idea and added 
the version 7 and set it as default for the Ignite project. However, 
every time I try to build the ignite-core module, it complains about 
"invalid source release: 1.8". Clearly I am missing something - but 
what? Are there any instructions anyone can point to for switching JDKs 
in IntelliJ?


Thanks!

Re: 'Date' and 'Timestamp' types in SQL queries

[Igor Sapego]

Ok, It seems like I have found what was causing the issue.

In our
apache.ignite.internal.processors.queryh.h2.IgniteH2Indexing.DBTypeEnum:

/**
 * Initialize map of DB types.
 */
static {
map.put(int.class, INT);
map.put(Integer.class, INT);
map.put(boolean.class, BOOL);
map.put(Boolean.class, BOOL);
map.put(byte.class, TINYINT);
map.put(Byte.class, TINYINT);
map.put(short.class, SMALLINT);
map.put(Short.class, SMALLINT);
map.put(long.class, BIGINT);
map.put(Long.class, BIGINT);
map.put(BigDecimal.class, DECIMAL);
map.put(double.class, DOUBLE);
map.put(Double.class, DOUBLE);
map.put(float.class, REAL);
map.put(Float.class, REAL);
map.put(Time.class, TIME);
map.put(Timestamp.class, TIMESTAMP);
map.put(java.util.Date.class, TIMESTAMP);
map.put(java.sql.Date.class, DATE);
map.put(String.class, VARCHAR);
map.put(UUID.class, UUID);
map.put(byte[].class, BINARY);
}

As I was using java.util.Date and not the java.sql.Date it was translated
as TIMESTAMP
and not as DATE. Are there any particular reason for java.util.Date being
treated as a
TIMESTAMP?

In our Binary marshaler we use java.sql.Date and when I try to change
configuration and
make the Date field to be of the type java.sql.Date I've got an error,
because this field value
deserialized as java.sql.Date:

lass org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:831)
[...]
at
org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.iterator(PlatformAbstractQueryCursor.java:134)
Caused by: org.h2.jdbc.JdbcSQLException: "java.lang.ClassCastException:
java.util.Date cannot be cast to java.sql.Date"


Best Regards,
Igor

On Thu, Feb 11, 2016 at 12:39 PM, Vladimir Ozerov 
wrote:

> There was some changes in how .NET interoperate w/ Java on binary level. No
> changes were made to cache or query logic.
> I performed a smoke test in Java and observed that Date field was correctly
> mapped to H2 date and then vice versa.
>
> Probably this is a kind of configuration problem.
>
> Vladimir.
>
> On Thu, Feb 11, 2016 at 12:41 AM, Dmitriy Setrakyan  >
> wrote:
>
> > I remember seeing some work done for the .NET support to provide better
> > precision for time data values. Could it be that SQL now converts
> > everything to Timestamp because of that?
> >
> > D.
> >
> > On Wed, Feb 10, 2016 at 10:09 AM, Igor Sapego 
> > wrote:
> >
> > > Hello,
> > >
> > > Recently I've been working on implementation of the Date and Timestamp
> > > types support for C++ client [1] and I today have faced an issue when I
> > was
> > > running tests with Date and SqlFieldQuery.
> > >
> > > Here is the issue. I have class that have field of type 'Date'. I was
> > able
> > > to create
> > > instances of that class and put them in a cache, but when I tried to
> > > retrieve
> > > these fields with SQL query I've got an exception. After the short
> debug
> > > session
> > > I have found that the values that SQL queries return are of type
> > > 'Timestamp'.
> > >
> > > So now I'm wonder, is it an expected behavior? Because to me it looks
> > like
> > > something that may be very confusing for a user. User knows that
> object's
> > > field
> > > is of type 'Date' but when they try to call GetNext on query row
> > they
> > > get an
> > > exception.
> > >
> > > I have also tested simple caches with Date where Date is a value and
> > these
> > > tests
> > > work just fine with 'Date' returned as a result of Cache#Get()
> requests.
> > >
> > > [1] - IGNITE-: CPP: Implement Date and Timestamp data types support
> > for
> > > binary protocol. 
> > > Best Regards,
> > > Igor
> > >
> >
>

Re: 'Date' and 'Timestamp' types in SQL queries

[Igor Sapego]

Sorry, I meant In our Binary marshaler we use *java.util.Date.*

Best Regards,
Igor

On Thu, Feb 11, 2016 at 6:12 PM, Igor Sapego  wrote:

> Ok, It seems like I have found what was causing the issue.
>
> In our
> apache.ignite.internal.processors.queryh.h2.IgniteH2Indexing.DBTypeEnum:
>
> /**
>  * Initialize map of DB types.
>  */
> static {
> map.put(int.class, INT);
> map.put(Integer.class, INT);
> map.put(boolean.class, BOOL);
> map.put(Boolean.class, BOOL);
> map.put(byte.class, TINYINT);
> map.put(Byte.class, TINYINT);
> map.put(short.class, SMALLINT);
> map.put(Short.class, SMALLINT);
> map.put(long.class, BIGINT);
> map.put(Long.class, BIGINT);
> map.put(BigDecimal.class, DECIMAL);
> map.put(double.class, DOUBLE);
> map.put(Double.class, DOUBLE);
> map.put(float.class, REAL);
> map.put(Float.class, REAL);
> map.put(Time.class, TIME);
> map.put(Timestamp.class, TIMESTAMP);
> map.put(java.util.Date.class, TIMESTAMP);
> map.put(java.sql.Date.class, DATE);
> map.put(String.class, VARCHAR);
> map.put(UUID.class, UUID);
> map.put(byte[].class, BINARY);
> }
>
> As I was using java.util.Date and not the java.sql.Date it was translated
> as TIMESTAMP
> and not as DATE. Are there any particular reason for java.util.Date being
> treated as a
> TIMESTAMP?
>
> In our Binary marshaler we use java.sql.Date and when I try to change
> configuration and
> make the Date field to be of the type java.sql.Date I've got an error,
> because this field value
> deserialized as java.sql.Date:
>
> lass org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:831)
> [...]
> at
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.iterator(PlatformAbstractQueryCursor.java:134)
> Caused by: org.h2.jdbc.JdbcSQLException: "java.lang.ClassCastException:
> java.util.Date cannot be cast to java.sql.Date"
>
>
> Best Regards,
> Igor
>
> On Thu, Feb 11, 2016 at 12:39 PM, Vladimir Ozerov 
> wrote:
>
>> There was some changes in how .NET interoperate w/ Java on binary level.
>> No
>> changes were made to cache or query logic.
>> I performed a smoke test in Java and observed that Date field was
>> correctly
>> mapped to H2 date and then vice versa.
>>
>> Probably this is a kind of configuration problem.
>>
>> Vladimir.
>>
>> On Thu, Feb 11, 2016 at 12:41 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>> wrote:
>>
>> > I remember seeing some work done for the .NET support to provide better
>> > precision for time data values. Could it be that SQL now converts
>> > everything to Timestamp because of that?
>> >
>> > D.
>> >
>> > On Wed, Feb 10, 2016 at 10:09 AM, Igor Sapego 
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > Recently I've been working on implementation of the Date and Timestamp
>> > > types support for C++ client [1] and I today have faced an issue when
>> I
>> > was
>> > > running tests with Date and SqlFieldQuery.
>> > >
>> > > Here is the issue. I have class that have field of type 'Date'. I was
>> > able
>> > > to create
>> > > instances of that class and put them in a cache, but when I tried to
>> > > retrieve
>> > > these fields with SQL query I've got an exception. After the short
>> debug
>> > > session
>> > > I have found that the values that SQL queries return are of type
>> > > 'Timestamp'.
>> > >
>> > > So now I'm wonder, is it an expected behavior? Because to me it looks
>> > like
>> > > something that may be very confusing for a user. User knows that
>> object's
>> > > field
>> > > is of type 'Date' but when they try to call GetNext on query row
>> > they
>> > > get an
>> > > exception.
>> > >
>> > > I have also tested simple caches with Date where Date is a value and
>> > these
>> > > tests
>> > > work just fine with 'Date' returned as a result of Cache#Get()
>> requests.
>> > >
>> > > [1] - IGNITE-: CPP: Implement Date and Timestamp data types
>> support
>> > for
>> > > binary protocol. 
>> > > Best Regards,
>> > > Igor
>> > >
>> >
>>
>
>

Re: 'Date' and 'Timestamp' types in SQL queries

[Igor Sapego]

I guess we should switch to java.sql.Date in BinaryMarshaller then.

Best Regards,
Igor

On Thu, Feb 11, 2016 at 7:20 PM, Sergi Vladykin 
wrote:

> This is because there is no java.util.Date in SQL, we have to either treat
> it as BLOB or as native SQL type Timestamp. We've chosen the latter
> approach.
>
> Sergi
>
> 2016-02-11 18:24 GMT+03:00 Igor Sapego :
>
> > Sorry, I meant In our Binary marshaler we use *java.util.Date.*
> >
> > Best Regards,
> > Igor
> >
> > On Thu, Feb 11, 2016 at 6:12 PM, Igor Sapego 
> wrote:
> >
> > > Ok, It seems like I have found what was causing the issue.
> > >
> > > In our
> > >
> apache.ignite.internal.processors.queryh.h2.IgniteH2Indexing.DBTypeEnum:
> > >
> > > /**
> > >  * Initialize map of DB types.
> > >  */
> > > static {
> > > map.put(int.class, INT);
> > > map.put(Integer.class, INT);
> > > map.put(boolean.class, BOOL);
> > > map.put(Boolean.class, BOOL);
> > > map.put(byte.class, TINYINT);
> > > map.put(Byte.class, TINYINT);
> > > map.put(short.class, SMALLINT);
> > > map.put(Short.class, SMALLINT);
> > > map.put(long.class, BIGINT);
> > > map.put(Long.class, BIGINT);
> > > map.put(BigDecimal.class, DECIMAL);
> > > map.put(double.class, DOUBLE);
> > > map.put(Double.class, DOUBLE);
> > > map.put(float.class, REAL);
> > > map.put(Float.class, REAL);
> > > map.put(Time.class, TIME);
> > > map.put(Timestamp.class, TIMESTAMP);
> > > map.put(java.util.Date.class, TIMESTAMP);
> > > map.put(java.sql.Date.class, DATE);
> > > map.put(String.class, VARCHAR);
> > > map.put(UUID.class, UUID);
> > > map.put(byte[].class, BINARY);
> > > }
> > >
> > > As I was using java.util.Date and not the java.sql.Date it was
> translated
> > > as TIMESTAMP
> > > and not as DATE. Are there any particular reason for java.util.Date
> being
> > > treated as a
> > > TIMESTAMP?
> > >
> > > In our Binary marshaler we use java.sql.Date and when I try to change
> > > configuration and
> > > make the Date field to be of the type java.sql.Date I've got an error,
> > > because this field value
> > > deserialized as java.sql.Date:
> > >
> > > lass org.apache.ignite.IgniteCheckedException: Failed to execute SQL
> > query.
> > > at
> > >
> >
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:831)
> > > [...]
> > > at
> > >
> >
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.iterator(PlatformAbstractQueryCursor.java:134)
> > > Caused by: org.h2.jdbc.JdbcSQLException: "java.lang.ClassCastException:
> > > java.util.Date cannot be cast to java.sql.Date"
> > >
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Thu, Feb 11, 2016 at 12:39 PM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > wrote:
> > >
> > >> There was some changes in how .NET interoperate w/ Java on binary
> level.
> > >> No
> > >> changes were made to cache or query logic.
> > >> I performed a smoke test in Java and observed that Date field was
> > >> correctly
> > >> mapped to H2 date and then vice versa.
> > >>
> > >> Probably this is a kind of configuration problem.
> > >>
> > >> Vladimir.
> > >>
> > >> On Thu, Feb 11, 2016 at 12:41 AM, Dmitriy Setrakyan <
> > >> dsetrak...@apache.org>
> > >> wrote:
> > >>
> > >> > I remember seeing some work done for the .NET support to provide
> > better
> > >> > precision for time data values. Could it be that SQL now converts
> > >> > everything to Timestamp because of that?
> > >> >
> > >> > D.
> > >> >
> > >> > On Wed, Feb 10, 2016 at 10:09 AM, Igor Sapego  >
> > >> > wrote:
> > >> >
> > >> > > Hello,
> > >> > >
> > >> > > Recently I've been working on implementation of the Date and
> > Timestamp
> > >> > > types support for C++ client [1] and I today have faced an issue
> > when
> > >> I
> > >> > was
> > >> > > running tests with Date and SqlFieldQuery.
> > >> > >
> > >> > > Here is the issue. I have class that have field of type 'Date'. I
> > was
> > >> > able
> > >> > > to create
> > >> > > instances of that class and put them in a cache, but when I tried
> to
> > >> > > retrieve
> > >> > > these fields with SQL query I've got an exception. After the short
> > >> debug
> > >> > > session
> > >> > > I have found that the values that SQL queries return are of type
> > >> > > 'Timestamp'.
> > >> > >
> > >> > > So now I'm wonder, is it an expected behavior? Because to me it
> > looks
> > >> > like
> > >> > > something that may be very confusing for a user. User knows that
> > >> object's
> > >> > > field
> > >> > > is of type 'Date' but when they try to call GetNext on query
> > row
> > >> > they
> > >> > > get an
> > >> > > exception.
> > >> > >
> > >> > > I have also tested simple caches with Date where Date is a value
> and
> > >> > these
> > >> > > tests
> > >> > > work just fine with 'Date' returned as a result of Cache#Get()
> > >> requests.
> > >> > >
> > >> > > [1] - IGNITE-: CPP: 

Re: 'Date' and 'Timestamp' types in SQL queries

[Vladimir Ozerov]

I do not think we are going to change BinaryMarshaller that way.
java.util.Date is widely used and accepted data type. To the contrast,
java.sql.Date is very specific data type usually used somewhere near JDBC
layer.

On Thu, Feb 11, 2016 at 11:06 PM, Igor Sapego  wrote:

> I guess we should switch to java.sql.Date in BinaryMarshaller then.
>
> Best Regards,
> Igor
>
> On Thu, Feb 11, 2016 at 7:20 PM, Sergi Vladykin 
> wrote:
>
> > This is because there is no java.util.Date in SQL, we have to either
> treat
> > it as BLOB or as native SQL type Timestamp. We've chosen the latter
> > approach.
> >
> > Sergi
> >
> > 2016-02-11 18:24 GMT+03:00 Igor Sapego :
> >
> > > Sorry, I meant In our Binary marshaler we use *java.util.Date.*
> > >
> > > Best Regards,
> > > Igor
> > >
> > > On Thu, Feb 11, 2016 at 6:12 PM, Igor Sapego 
> > wrote:
> > >
> > > > Ok, It seems like I have found what was causing the issue.
> > > >
> > > > In our
> > > >
> > apache.ignite.internal.processors.queryh.h2.IgniteH2Indexing.DBTypeEnum:
> > > >
> > > > /**
> > > >  * Initialize map of DB types.
> > > >  */
> > > > static {
> > > > map.put(int.class, INT);
> > > > map.put(Integer.class, INT);
> > > > map.put(boolean.class, BOOL);
> > > > map.put(Boolean.class, BOOL);
> > > > map.put(byte.class, TINYINT);
> > > > map.put(Byte.class, TINYINT);
> > > > map.put(short.class, SMALLINT);
> > > > map.put(Short.class, SMALLINT);
> > > > map.put(long.class, BIGINT);
> > > > map.put(Long.class, BIGINT);
> > > > map.put(BigDecimal.class, DECIMAL);
> > > > map.put(double.class, DOUBLE);
> > > > map.put(Double.class, DOUBLE);
> > > > map.put(float.class, REAL);
> > > > map.put(Float.class, REAL);
> > > > map.put(Time.class, TIME);
> > > > map.put(Timestamp.class, TIMESTAMP);
> > > > map.put(java.util.Date.class, TIMESTAMP);
> > > > map.put(java.sql.Date.class, DATE);
> > > > map.put(String.class, VARCHAR);
> > > > map.put(UUID.class, UUID);
> > > > map.put(byte[].class, BINARY);
> > > > }
> > > >
> > > > As I was using java.util.Date and not the java.sql.Date it was
> > translated
> > > > as TIMESTAMP
> > > > and not as DATE. Are there any particular reason for java.util.Date
> > being
> > > > treated as a
> > > > TIMESTAMP?
> > > >
> > > > In our Binary marshaler we use java.sql.Date and when I try to change
> > > > configuration and
> > > > make the Date field to be of the type java.sql.Date I've got an
> error,
> > > > because this field value
> > > > deserialized as java.sql.Date:
> > > >
> > > > lass org.apache.ignite.IgniteCheckedException: Failed to execute SQL
> > > query.
> > > > at
> > > >
> > >
> >
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:831)
> > > > [...]
> > > > at
> > > >
> > >
> >
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.iterator(PlatformAbstractQueryCursor.java:134)
> > > > Caused by: org.h2.jdbc.JdbcSQLException:
> "java.lang.ClassCastException:
> > > > java.util.Date cannot be cast to java.sql.Date"
> > > >
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > > On Thu, Feb 11, 2016 at 12:39 PM, Vladimir Ozerov <
> > voze...@gridgain.com>
> > > > wrote:
> > > >
> > > >> There was some changes in how .NET interoperate w/ Java on binary
> > level.
> > > >> No
> > > >> changes were made to cache or query logic.
> > > >> I performed a smoke test in Java and observed that Date field was
> > > >> correctly
> > > >> mapped to H2 date and then vice versa.
> > > >>
> > > >> Probably this is a kind of configuration problem.
> > > >>
> > > >> Vladimir.
> > > >>
> > > >> On Thu, Feb 11, 2016 at 12:41 AM, Dmitriy Setrakyan <
> > > >> dsetrak...@apache.org>
> > > >> wrote:
> > > >>
> > > >> > I remember seeing some work done for the .NET support to provide
> > > better
> > > >> > precision for time data values. Could it be that SQL now converts
> > > >> > everything to Timestamp because of that?
> > > >> >
> > > >> > D.
> > > >> >
> > > >> > On Wed, Feb 10, 2016 at 10:09 AM, Igor Sapego <
> isap...@gridgain.com
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hello,
> > > >> > >
> > > >> > > Recently I've been working on implementation of the Date and
> > > Timestamp
> > > >> > > types support for C++ client [1] and I today have faced an issue
> > > when
> > > >> I
> > > >> > was
> > > >> > > running tests with Date and SqlFieldQuery.
> > > >> > >
> > > >> > > Here is the issue. I have class that have field of type 'Date'.
> I
> > > was
> > > >> > able
> > > >> > > to create
> > > >> > > instances of that class and put them in a cache, but when I
> tried
> > to
> > > >> > > retrieve
> > > >> > > these fields with SQL query I've got an exception. After the
> short
> > > >> debug
> > > >> > > session
> > > >> > > I have found that the values that SQL queries return are of type
> > > >> > > 'Timestamp'.
> > > >> > >
> > > 

Re: Compiling Ignite against different JDKs

[Valentin Kulichenko]

Hi,

Most likely you have 'java8' profile enabled. Go to Maven
Projects->Profiles and remove the corresponding checkbox.

-Val

On Thu, Feb 11, 2016 at 6:35 AM, Dood@ODDO  wrote:

> Hello all,
>
> I am working on a ticket that is not very difficult, if you are good with
> Idea, Java, Maven etc. I have been a developer in various languages but new
> to Java ;).
>
> I had JDK8 installed and I introduced some changes to the code base that
> cause it to not compile (apparently) against the JDK7. I downloaded JDK7
> and installed it, I went into Project Structure->JDKs in Idea and added the
> version 7 and set it as default for the Ignite project. However, every time
> I try to build the ignite-core module, it complains about "invalid source
> release: 1.8". Clearly I am missing something - but what? Are there any
> instructions anyone can point to for switching JDKs in IntelliJ?
>
> Thanks!
>

[jira] [Created] (IGNITE-2625) .NET: Incorrect field offset calculation in BinaryReader

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2625:
--

 Summary: .NET: Incorrect field offset calculation in BinaryReader
 Key: IGNITE-2625
 URL: https://issues.apache.org/jira/browse/IGNITE-2625
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.6


See BinaryReader.SeekField(string), position from _curSchemaMap is used as is, 
and does not take current object offset (_curPos) into account.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: MyBatis-Ignite integration release

[Roman Shtykh]

Dmitriy,
Let's see if we have some feedback from users (that is mostly the intention I 
share here too). After that I'll call for a vote among MyBatis devs and they 
will help with the release.
-Roman
 

On Thursday, February 11, 2016 5:39 PM, Dmitriy Setrakyan 
 wrote:
 

 Thanks Roman, this is awesome news! 
Do you know what is the process at MyBatis to move from beta into a final GA 
release?
D.
On Wed, Feb 10, 2016 at 11:41 PM, Roman Shtykh  wrote:

Dear community,

I would like to share the news about MyBatis-Ignite integration release, as a 
result of the collaboration between Ignite and MyBatis teams.

http://blog.mybatis.org/2016/02/mybatis-ignite-released.html

>From now please consider using Apache Ignite as your 2nd level MaBatis cache.

Best regards,
Roman




  

[jira] [Created] (IGNITE-2627) ODBC: OdbcNioParser is implemented incorrectly.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2627:
---

 Summary: ODBC: OdbcNioParser is implemented incorrectly.
 Key: IGNITE-2627
 URL: https://issues.apache.org/jira/browse/IGNITE-2627
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6


There are number of problem with OdbcNioParser which makes it usable only in 
single-threaded application when no TCP messages are batched together:

1) Parser is not thread-safe and hence cannot have any state like 
"leftToReceive" of "curMsg" fields.
Instead, you should rely on meta assigned to GridNioSession. See 
GridDirectParser as example. 
This will make the parser thread-safe.

2) Message is decoded incorrectly. When "decode" is called, you cannot rely on 
buf.array(), as this array could contain multiple requests. Moreover, there are 
no guarantees that current message is started from the beginning of this array. 
So, the following line might return incorrect result:
{code}
int msgLen = reader.readInt();
{code}

Instead, you should follow common practice:
1) Always rely on ByteBuffer.remaining()
2) Read message byte-by-byte until all 4 bytes are read.
3) Then read message body into separate byte[] until all data is ready.
4) And only then you can create BinaryHeapInputStream and deserialize the stuff.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2628) ODBC: Add multi-threaded tests.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2628:
---

 Summary: ODBC: Add multi-threaded tests.
 Key: IGNITE-2628
 URL: https://issues.apache.org/jira/browse/IGNITE-2628
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 1.6






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2629) ODBC: Added GridNioAsyncNotifyFilter and GridConnectionBytesVerifyFilter to NIO server.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2629:
---

 Summary: ODBC: Added GridNioAsyncNotifyFilter and 
GridConnectionBytesVerifyFilter to NIO server.
 Key: IGNITE-2629
 URL: https://issues.apache.org/jira/browse/IGNITE-2629
 Project: Ignite
  Issue Type: Sub-task
  Components: odbc
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
Priority: Minor
 Fix For: 1.6


This is low-priority task, lets return to it once everything else is finished.

Justification:
1) *GridNioAsyncNotifyFilter* moves requests processing to separate thread 
pool. If you do no do that, all NIO workers might stuck in potentially 
long-running query operations and you will not be able to accept new client 
requests what may result in timeouts on client side.
2) *GridConnectionBytesVerifyFilter* expects special magic header to ensure 
connected client identity.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2630) Make 'updateCntr' available through CacheInterceptor API

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-2630:


 Summary: Make 'updateCntr' available through CacheInterceptor API
 Key: IGNITE-2630
 URL: https://issues.apache.org/jira/browse/IGNITE-2630
 Project: Ignite
  Issue Type: New Feature
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Nikolay Tikhonov
Priority: Minor


Make {{updateCntr}} available through {{CacheInterceptor}} API. On 
{{onAfterPut}} and {{onAfterRemove}} methods partition update counter can be 
got by Cache.Entry.unwrap(Long.class). When invoking other methods on 
{{CacheIntercetor}} API ({{onBeforePut}}, {{onBeforeRemove}}) the counter is 
not available.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 'Date' and 'Timestamp' types in SQL queries

[Sergi Vladykin]

This is because there is no java.util.Date in SQL, we have to either treat
it as BLOB or as native SQL type Timestamp. We've chosen the latter
approach.

Sergi

2016-02-11 18:24 GMT+03:00 Igor Sapego :

> Sorry, I meant In our Binary marshaler we use *java.util.Date.*
>
> Best Regards,
> Igor
>
> On Thu, Feb 11, 2016 at 6:12 PM, Igor Sapego  wrote:
>
> > Ok, It seems like I have found what was causing the issue.
> >
> > In our
> > apache.ignite.internal.processors.queryh.h2.IgniteH2Indexing.DBTypeEnum:
> >
> > /**
> >  * Initialize map of DB types.
> >  */
> > static {
> > map.put(int.class, INT);
> > map.put(Integer.class, INT);
> > map.put(boolean.class, BOOL);
> > map.put(Boolean.class, BOOL);
> > map.put(byte.class, TINYINT);
> > map.put(Byte.class, TINYINT);
> > map.put(short.class, SMALLINT);
> > map.put(Short.class, SMALLINT);
> > map.put(long.class, BIGINT);
> > map.put(Long.class, BIGINT);
> > map.put(BigDecimal.class, DECIMAL);
> > map.put(double.class, DOUBLE);
> > map.put(Double.class, DOUBLE);
> > map.put(float.class, REAL);
> > map.put(Float.class, REAL);
> > map.put(Time.class, TIME);
> > map.put(Timestamp.class, TIMESTAMP);
> > map.put(java.util.Date.class, TIMESTAMP);
> > map.put(java.sql.Date.class, DATE);
> > map.put(String.class, VARCHAR);
> > map.put(UUID.class, UUID);
> > map.put(byte[].class, BINARY);
> > }
> >
> > As I was using java.util.Date and not the java.sql.Date it was translated
> > as TIMESTAMP
> > and not as DATE. Are there any particular reason for java.util.Date being
> > treated as a
> > TIMESTAMP?
> >
> > In our Binary marshaler we use java.sql.Date and when I try to change
> > configuration and
> > make the Date field to be of the type java.sql.Date I've got an error,
> > because this field value
> > deserialized as java.sql.Date:
> >
> > lass org.apache.ignite.IgniteCheckedException: Failed to execute SQL
> query.
> > at
> >
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:831)
> > [...]
> > at
> >
> org.apache.ignite.internal.processors.platform.cache.query.PlatformAbstractQueryCursor.iterator(PlatformAbstractQueryCursor.java:134)
> > Caused by: org.h2.jdbc.JdbcSQLException: "java.lang.ClassCastException:
> > java.util.Date cannot be cast to java.sql.Date"
> >
> >
> > Best Regards,
> > Igor
> >
> > On Thu, Feb 11, 2016 at 12:39 PM, Vladimir Ozerov 
> > wrote:
> >
> >> There was some changes in how .NET interoperate w/ Java on binary level.
> >> No
> >> changes were made to cache or query logic.
> >> I performed a smoke test in Java and observed that Date field was
> >> correctly
> >> mapped to H2 date and then vice versa.
> >>
> >> Probably this is a kind of configuration problem.
> >>
> >> Vladimir.
> >>
> >> On Thu, Feb 11, 2016 at 12:41 AM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> >> wrote:
> >>
> >> > I remember seeing some work done for the .NET support to provide
> better
> >> > precision for time data values. Could it be that SQL now converts
> >> > everything to Timestamp because of that?
> >> >
> >> > D.
> >> >
> >> > On Wed, Feb 10, 2016 at 10:09 AM, Igor Sapego 
> >> > wrote:
> >> >
> >> > > Hello,
> >> > >
> >> > > Recently I've been working on implementation of the Date and
> Timestamp
> >> > > types support for C++ client [1] and I today have faced an issue
> when
> >> I
> >> > was
> >> > > running tests with Date and SqlFieldQuery.
> >> > >
> >> > > Here is the issue. I have class that have field of type 'Date'. I
> was
> >> > able
> >> > > to create
> >> > > instances of that class and put them in a cache, but when I tried to
> >> > > retrieve
> >> > > these fields with SQL query I've got an exception. After the short
> >> debug
> >> > > session
> >> > > I have found that the values that SQL queries return are of type
> >> > > 'Timestamp'.
> >> > >
> >> > > So now I'm wonder, is it an expected behavior? Because to me it
> looks
> >> > like
> >> > > something that may be very confusing for a user. User knows that
> >> object's
> >> > > field
> >> > > is of type 'Date' but when they try to call GetNext on query
> row
> >> > they
> >> > > get an
> >> > > exception.
> >> > >
> >> > > I have also tested simple caches with Date where Date is a value and
> >> > these
> >> > > tests
> >> > > work just fine with 'Date' returned as a result of Cache#Get()
> >> requests.
> >> > >
> >> > > [1] - IGNITE-: CPP: Implement Date and Timestamp data types
> >> support
> >> > for
> >> > > binary protocol.  >
> >> > > Best Regards,
> >> > > Igor
> >> > >
> >> >
> >>
> >
> >
>

[GitHub] ignite pull request: Ignite 2430

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

https://github.com/apache/ignite/pull/475

Ignite 2430



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dkarachentsev/ignite ignite-2430

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/475.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #475


commit 946dccb9e98419bf9921b12607667d74ef87ecda
Author: dkarachentsev 
Date:   2016-02-10T08:33:04Z

IGNITE-2575 Add limit on minimal value of IGFS IPC port configuration.

commit 3d5999821d0efd6c026adbb3256c86bc798dc1c7
Author: dkarachentsev 
Date:   2016-02-10T08:50:09Z

Merge remote-tracking branch 'upstream/master'

commit 375eb11ba8c9076906971785fdb7bead294d8022
Author: dkarachentsev 
Date:   2016-02-11T09:47:18Z

Merge remote-tracking branch 'upstream/master'

commit 9cbee07c3a44de71dc25aa0ef23f620c12a0ecc4
Author: dkarachentsev 
Date:   2016-02-11T16:12:18Z

GNITE-2430 - Fix BinaryObject: Inconsistent field type name is returned for 
Collections




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-2631) Add ability to view java- and xml- files from 'Project structure'

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2631:
--

 Summary: Add ability to view java- and xml- files from 'Project 
structure'
 Key: IGNITE-2631
 URL: https://issues.apache.org/jira/browse/IGNITE-2631
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2555 fix

[ruskim]

Github user ruskim closed the pull request at:

https://github.com/apache/ignite/pull/468


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-2626) Binary marshaller: sort fields alphabetically

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2626:
--

 Summary: Binary marshaller: sort fields alphabetically
 Key: IGNITE-2626
 URL: https://issues.apache.org/jira/browse/IGNITE-2626
 Project: Ignite
  Issue Type: Improvement
  Components: cache, platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
 Fix For: 1.6


Currently we write object fields in the order they come from reflection.
1) There is no guarantee that this order is consistent across multiple calls
2) Platforms may have corresponding objects with different field order

=> There are situations when write and read field order is different, which 
hurts performance.

Sorting fields alphabetically in Java and platforms will ensure the same 
ordering.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Transformers in SCAN queries

[Dmitriy Setrakyan]

On Thu, Feb 11, 2016 at 6:18 AM, Andrey Gura  wrote:

> Despite of trasformer makes little sense for the SqlFieldsQuery I don't see
> any reason for throwing of UnsupportedOperationException.
> I think it is stange limitation from user standpoint.
>

I think either supporting it or not supporting looks strange for
SqlFieldsQuery. I suggested to throw the exception only to simplify the
development - simply one less thing to worry about.


>
> On Thu, Feb 11, 2016 at 6:01 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > I changed the description in the ticket. If anyone has comments about the
> > implementation details, feel free to add them there.
> >
> > -Val
> >
> > On Wed, Feb 10, 2016 at 2:30 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > I like the new method on IgniteCache API:
> > >
> > >  QueryCursor query(Query qry, Transformer transformer);
> > >
> > > I do agree that it makes little sense for the SqlFieldsQuery, but we
> can
> > > simply throw an unsupported exception here. For all other queries it
> does
> > > make sense.
> > >
> > > Val, can you put together all the thoughts expressed in this thread
> into
> > a
> > > ticket?
> > >
> > > D.
> > >
> > > On Thu, Feb 4, 2016 at 4:14 PM, Andrey Gura 
> wrote:
> > >
> > > > Val,
> > > >
> > > > From my point of view, special query class that allows transforming
> is
> > > > confusing. Two points about it:
> > > >
> > > > 1. ScanTransformQuery will duplicate ScanQuery code with all
> drawbacks
> > > that
> > > > we have. Moreover, any fix for ScanQuery should be repeated for
> > > > ScanTransformQuery. It will lead to bugs. DRY.
> > > >
> > > > 2. If some users want to do transformations for SqlQuery we will
> > > introduce
> > > > SqlTransformQuery. Right? At this point see previous item.
> > > >
> > > > Transformation logic is some kind of strategy. IMHO, the most
> > convenient
> > > > API should get transformation logic as some function provided by
> user.
> > > >
> > > > On Thu, Feb 4, 2016 at 11:05 PM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Agree with Sergi. Mixing SQL with Java code transformers is
> > confusing.
> > > In
> > > > > rare case when it's really required, user can implement a custom
> > > > function.
> > > > >
> > > > > I copy-pasted the API to the ticket [1]. Please provide any
> > additional
> > > > > comments there.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-2546
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Feb 4, 2016 at 10:08 AM, Andrey Gura 
> > > wrote:
> > > > >
> > > > > > Sergi,
> > > > > >
> > > > > >
> > > > > > > What you are going to transform remotely here?
> > > > > >
> > > > > >
> > > > > > I'm not going. I believe :)
> > > > > >
> > > > > > Just hypothetical use case: You have one SqlFieldsQuery but
> > different
> > > > > > requirements for returned values. For one case you have to return
> > > some
> > > > > > string fields as is and for another case you have to trim string
> to
> > > 32
> > > > > > characters. Of course you still can trim strings locally but
> > > > transformers
> > > > > > allow you do it remotely.
> > > > > >
> > > > > > Anyway, this solution can be usefull for rest query types.
> > > > > >
> > > > > > On Thu, Feb 4, 2016 at 8:54 PM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > The whole point of Transformer is to do remote transform, how
> > will
> > > > this
> > > > > > > work with SqlFieldsQuery? What you are going to transform
> > remotely
> > > > > here?
> > > > > > I
> > > > > > > believe all the transformations must happen at SQL level here.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2016-02-04 20:10 GMT+03:00 Andrey Gura :
> > > > > > >
> > > > > > > > SqlQuery, TextQuery and SpiQuery are similar to ScanQuery
> > because
> > > > all
> > > > > > of
> > > > > > > > them also defined as Query>.
> > > > > > > >
> > > > > > > > It can be usefull to have one query SqlQuery that can return
> > > > > different
> > > > > > > > result that will be produced from cache entry by transformer.
> > > > > > > >
> > > > > > > > Actually only SqlFieldsQuery has different definition. So
> > > > > transformers
> > > > > > > can
> > > > > > > > be applied to any type of query (including SqlFieldsQuery, I
> > > > > believe).
> > > > > > > >
> > > > > > > > On Thu, Feb 4, 2016 at 7:42 PM, Sergi Vladykin <
> > > > > > sergi.vlady...@gmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I don't like the idea of having additional method
> > > *query(Query
> > > > > > qry,
> > > > > > > > > Transformer transfomer); *because I don't see how
> these
> > > > > > > > transformers
> > > > > > > > > will work for example with SQL, but this API makes