sorry for not mentioning it right away.. the version is 1.4.177 and URL
jdbc:h2:./db/test;IFEXISTS=TRUE;LOCK_TIMEOUT=3
On Thursday, May 15, 2014 2:27:49 PM UTC+2, Noel Grandin wrote:
which version are you using and what does your database URL look like?
--
You received this message
There is known bug at the moment with 1.4.177 which results in increased file
size for some people.
Either disable the new MVStore engine by appending ;MV_STORE=FALSE to your JDBC URL, or fall back to the latest 1.3.x
release.
On 2014-05-16 09:14, too wrote:
sorry for not mentioning it
I can confirm the problem. We tried to move from 1.3.172 to 1.3.174 and got
the same error.
On Friday, May 9, 2014 4:12:29 PM UTC+2, Germano Rizzo wrote:
If I remove the foreign key definition (last line in the SQL) the problem
doesn't present itself.
Of course I can't do this, as I have
I'm just looking at the created indexes and getting with
SELECT sql, index_class
FROM information_schema.indexes
WHERE table_name = 'USER' AND primary_key = FALSE
this result
SQL
http://localhost:8082/query.do?jsessionid=4543ce724e0a897791e57bfcdcc8807b#
INDEX_CLASS
We only have real hash indexes for in-memory databases.
For persistent databases, the hash qualifier doesn't do anything.
What did you think a persistent hash-index would look like, if not a b-tree ?
On 2014-05-16 13:28, Martin Grajcar wrote:
It puzzles me that the PageBtreeIndex gets used
Thank you for the quick answer. My though was that I don't need any
ordering so I'd go for the faster option. But actually I don't care.
How should a persistent hash-index look like? Maybe something like
Clojure's HashMap, maybe an optimized subclass of PageBtreeIndex? Am I a
database writer? :D
Has anyone come across issues with H2 where divisions are not working as
expected.
In the example below, one would expect both calcualtions to result into
same value but the results are shockingly different.
select 0.7217942515034725091231155080 / 5314251955.21 as BAD,
That's a funny bug! It's stripping trailing zeros from
1.35822361752313607260107721120531135706133161972E-1*0*
:D
ValueDecimal.java:101
On Fri, May 16, 2014 at 12:37 PM, Ankur Goyal getan...@gmail.com wrote:
Has anyone come across issues with H2 where divisions are not working as
Thank you for the test-case.
This bug has been fixed in SVN.
On 2014-05-16 12:37, Ankur Goyal wrote:
Has anyone come across issues with H2 where divisions are not working as
expected.
--
You received this message because you are subscribed to the Google Groups H2
Database group.
To
Hello,
Sorry for resurrecting the thread when the conversation seem to have
concluded.
As in the original posting, I see a similar synchronization bottleneck in
DateTimeUtils.dateValueFromDate method on a global calendar instance:
public static long dateValueFromDate(long ms) {
10 matches
Mail list logo
