[h2] When is the next official release?

Hi all, The latest official version is 1.4.200 (2019-10-14). There are several fixes that are of interest for us but it is unclear when there is going to be a release containing these. Any idea when the next official release is? Cheers, -Christopher -- You received this message because you ar

[h2] NPE after upgrade from H2 4.1.197 to any later version

Hi all, I just upgraded H2 from 1.4.197 to 1.4.200 and we are now hitting a NPE. I narrowed down the case and it seems to be related to executing multiple statements in 1, with a specific sequence. Out of curiosity I tried 1.4.198 and 1.4.199 and the bug also occurs there. The statement (to be ex

Re: [h2] Metadata and actual values column class mismatch

Hi Thomas, I will test this patch and commit it if I don't find problems. > Thanks! Please let me know when it is committed so I can do further testing on my end. Cheers, -Christopher -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubsc

Re: [h2] Metadata and actual values column class mismatch

Noel, Thomas, By any chance, did you have some time to look into this metadata type issue? Cheers, -Christopher -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [h2] Metadata and actual values column class mismatch

Hi Noel, By default constant values are interpreted as decimal. If you want them to > be doubles, you will need to explicitly cast them I don't mind the constants to return a decimal, but then metadata should not lie about the type that is returned. Don't you think it is a bug that a decimal is

[h2] Metadata and actual values column class mismatch

Hi all, We found a case where metadata from a resultset declares a column class (a "java.lang.Double") but a value happens to not match (it is a "java.math.BigDecimal"). We base some logic on these column classes (like sorting in UI), and our code breaks (class cast exceptions). The culprit se

Re: [h2] Negative zero of DOUBLE type

Steve, Thomas, Eventually, H2 1.4 (with the MVStore) will be marked stable. Maybe this > will be the next release, but I'm not sure yet. > Fair enough, I will try to integrate 1.4 without the MVStore. In fact, according to the H2 documentation, it is off by default: http://www.h2database.com/ja

Re: [h2] Negative zero of DOUBLE type

Hi Steve, > You can use the latest H2 1.4 release with MV_STORE=false in the JDBC URL. > I wish I could use 1.4! Unfortunately, 1.4 is still marked as Beta and we can only include an officially stable version. Cheers, -Christopher -- You received this message because you are subscribed to t

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, Do you have any plans on releasing an official 1.3.x version containing the > fix? > Any news? Cheers, -Christopher -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it,

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, > OK, this is now committed. > Great news! Do you have any plans on releasing an official 1.3.x version containing the fix? Cheers, -Christopher -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, > Changing ValueFloat.get and ValueDouble.get should be enough, but I didn't > test it yet. > You are spot on! In fact, you had dedicated code to try to handle -0.0, and removing it solved all the issues ("ABS(x)" works, and no more negative zeros!). Now the SELECT test case I ind

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, > A patch with simple test cases would be nice (maybe a simple SQL script > with a few cases). I would like to test this with other databases as well. > A simple test case where all columns should be TRUE: SELECT (CAST('-0.0' AS DOUBLE)) = (CAST('0.0' AS DOUBLE)), ((CAST('-0.0' AS

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, > I think we have two options: support -0.0 (as we do now), or completely > remove support for it. I don't see a way that we can support it on some > places, but not support it in other places. > Fair enough, but then -0.0 should not be supported. > It looks like this is what o

Re: [h2] Negative zero of DOUBLE type

Hi Noel, Java uses the IEEE spec for floating point numbers, which for reasons > beyond my understanding, has a concept of positive and negative zero. > Actually, in Java, this concept of a negative zero is not a problem. Let me explain: there are 2 cases. Note that I will talk about Double,

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, > As I wrote before, H2 uses Double.compare(x, y), which first checks the > sign. > Well, I am strongly questioning that choice. You should probably do the following instead: "x == y? 0: Double.compare(x, y)". This could lead to a discussion on the NaN, but I think either choice is

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, I realized I did not test the behavior of all comparison operators. I found that in Java: 0.0 == -0.0 is true -0.0 < 0.0 is false SELECT (CAST('-0.0' AS DOUBLE)) = -(CAST('-0.0' AS DOUBLE)), (CAST('-0.0' AS DOUBLE)) < -(CAST('-0.0' AS DOUBLE)) H2 will say that: 0.0 == -0.0 is false

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, I did further testing and have some new findings. Consider this test case: SELECT -(CAST('-0.0' AS DOUBLE)) = ZERO(), (CAST('-0.0' AS DOUBLE)) = -ZERO(), -(CAST('0.0' AS DOUBLE)) = ZERO(), (CAST('0.0' AS DOUBLE)) = -ZERO(), (CAST('-0.0' AS DOUBLE)) = (CAST('0.0' AS DOUBLE)) Apart from

Re: [h2] Negative zero of DOUBLE type

Hi Thomas, ABS(0.0) is negative zero. >> > > I think this is a bug, I will fix it. > Yes, with this one fixed, I guess we can prevent -0.0 from happening. > I think because Java supports -0.0, H2 should also support it. I will keep > this behavior for now. > Fair enough. I just hope standa

[h2] Negative zero of DOUBLE type

Hi all, We have a problem with zeros of DOUBLE type, as well as negative zeros. We are using the latest stable H2 1.3.176. The odd behaviors we found are: -0.0 is allowed and not turned into 0.0. -0.0 is not zero. ABS(-0.0) is zero. ABS(0.0) is negative zero. To test zero, we have to test (x = Z

Re: Java Object ORDER BY and VARCHAR comparisons

Hi Rami, > "Setting this to 'false' is experimental." I know, but it is this very setting that allows us to use H2. > My advice: Be more insensitive, I mean case-insensitive. Yeah, we do what we can. Do not underestimate case sensitivity though, because it allows interesting integration scenar

Re: Java Object ORDER BY and VARCHAR comparisons

Hi Remi, > Domain is the sql term for type > That's the concept around which custom types and inheritance should be > built. Thanks, declaring my own type is an improvement already: CREATE DOMAIN MYOBJECT AS OTHER > If the DBMS already supports the basic types like "list of characters", > "integ

Re: Java Object ORDER BY and VARCHAR comparisons

Hi Sergi, > As I wrote you can write your query as > select * from data where cast(object as varchar) = 'bla' Yes I know, but what I am looking for is a compelling argument. My logic is: - String to Object is inherently not possible. - Object to String is possible. - Why does H2 try to convert St

Serialized vs not serialized objects and system property

Hi all, We use several in-memory H2 databases for different purposes. Some are purely internal for consumption of intermediate results, some are exposed to external tools. They are really independant and there can be multiple databases up at the same time. For internal consumption, we don't want

Re: Java Object ORDER BY and VARCHAR comparisons

Hi Thomas, > If you are interested in the string representation, why don't you just > use varchar? I would if I could, but I can't so I won't. > It's good that you care about your use case, but there > are other uses cases to be considered. Yes, let's come to that, and let's be pragmatic. It's

Re: Java Object ORDER BY and VARCHAR comparisons

Hi Thomas, > The current implementation of this feature is geared towards high > performance, which means trying to avoid serialization (at least for > in-memory databases), trying to avoid calling toString, and rather > calling the classes compareTo, hashCode, and equals methods. There is no per

Re: Java Object ORDER BY and VARCHAR comparisons

> This is known limitation. Currently H2 does not know how to convert string > to your object type other then to parse hexadecimal data. This is not the problem. The real problem is that Strings are trying to be transformed to the Java object rather than transforming the Java object to String. Whe

Re: Java Object ORDER BY and VARCHAR comparisons

Hi Noel, > I'd be willing to take the Comparable part of this patch if it included an > addition to our unit-test framework. (hint, hint :-) I was about to set it up to work on it when I saw the following: "Version 1.3.168 (2012-07-13) New system property "h2.serializeJavaObject" (default: true)

Re: Multi statement JDBC query, getMoreResults() and getUpdateCount() issue.

Hi Noel, > Yeah, unfortunately we don't support that part of the JDBC spec yet. Thanks for the info! > Patches would be welcome :-) I will keep it in mind, in case I get a bit of free time to play with H2 internals. By-the-way, any advices on where I should start, things to know, etc.? Cheers,

Re: Java Object ORDER BY and VARCHAR comparisons

Hi Steve, > Comparing an Object with a String using toString() seems to me like a misuse > of toString(). It will solve your particular case, but I don't think it is a > good general approach. Well, if like Comparable a marker interface would remove that feel of misuse, then so be it. But toStrin

Multi statement JDBC query, getMoreResults() and getUpdateCount() issue.

Hi, Using H2 (h2-2012-05-23) with JDBC, I am facing the following issue: I am sending a user-defined statement, which may contain multiple operations, where we are eventually interested in the returned resultset of the last statement. The problem is that it seems those JDBC methods don't work:

Java Object ORDER BY and VARCHAR comparisons

Hi, We are using H2 (h2-2012-05-23) and we faced a few issues. One of them is that I replaced a VARCHAR field with a Java object (OTHER) that contains the string and some additional information. The problem now is that it breaks existing ORDER BY clauses and equality tests with VARCHARs, though