I think Igor's suggestion is fine. Essentially it mean that we will operate
on the most "precise" data and convert it to less precise only if user
explicitly requested it by choosing less precise data type.
On Fri, Feb 12, 2016 at 8:09 PM, Dmitriy Setrakyan
wrote:
> Igor,
>
> I will wait for Vov
Igor,
I will wait for Vova to comment on your last suggestion. Just wanted to add
that we should be careful not to loose any precision during the conversion,
as we got hit by it in the past.
D.
On Fri, Feb 12, 2016 at 1:36 AM, Igor Sapego wrote:
> Ok, then I propose following solution: when us
Ok, then I propose following solution: when user of the C++ client tries
to read 'Date' value when there is an 'Timestamp' value in a stream
implicit cast from 'Timestamp' to 'Date' happens and user gets his
value.
What do you think?
Best Regards,
Igor
On Thu, Feb 11, 2016 at 11:25 PM, Vladimir
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
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
> appr
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
>
> O
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:
>
> /**
> *
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, BOO
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
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
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 th
11 matches
Mail list logo
