Re: [h2] Unique index or primary key violation: SYS_ID ON PUBLIC.SYS(ID) [23505-168] (using 1.3.168)
Hi, If you are using LOCK_MODE=0;UNDO_LOG=0 then you need to be aware of the risks. See the FAQ and the documentation. Please use different email subjects for different problems. Regards, Thomas On Monday, May 5, 2014, mano germano.ri...@gmail.com wrote: mano wrote Opening it with version 1.3.168 will give the error. Sorry, I meant 1.3.176. -- View this message in context: http://h2-database.66688.n3.nabble.com/Unique-index-or-primary-key-violation-SYS-ID-ON-PUBLIC-SYS-ID-23505-168-using-1-3-168-tp4028700p4029078.html Sent from the H2 Database mailing list archive at Nabble.com. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
Hi Thomas, the problem you are talking about only exists when dealing with date values without time, like 1982-01-01, not for Timestamp values. We could store timestamps internally as a long value, defined in the same way as that System.currentTimeMillis is defined i.e. milliseconds since 1 Jan 1970 GMT. Then there are no daylight saving or midnight problems, because by definition it is unambiguous. See here for a fuller explanation: http://en.wikipedia.org/wiki/Unix_time http://en.wikipedia.org/wiki/Coordinated_Universal_Time Regards, Noel. On 2014-05-06 07:57, Thomas Mueller wrote: Hi, There are various problems when using java.util.Data / java.sql.Date / Time / Timestamp and java.util.Calendar, mainly because of the daylight time saving changes. For example, you can't assume a certain date (if you don't care about the time) is midnight, because in some timezones, for some days, midnight doesn't exist because it's the daylight time saving border. It's not a problem in most timezones, but it is in some. Regards, Thomas On Monday, May 5, 2014, Noel Grandin noelgran...@gmail.com mailto:noelgran...@gmail.com wrote: I'm curious - why do we not simply store date and time in UTC format? i.e. in milliseconds since 1 Jan 1970? That's pretty much a universal format these days, and then we can convert to whatever the local time zone is when we convert the value to string. If necessary, I could create an extra data type to represent time like this? I know I would use it, since that's how we represent all our data. -- 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 h2-database+unsubscr...@googlegroups.com javascript:;. To post to this group, send email to h2-database@googlegroups.com javascript:;. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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 h2-database+unsubscr...@googlegroups.com mailto:h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com mailto:h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
Intuitively, I would agree with Noel, here. The unix timestamp (plus nano seconds) seems to be a reliable storage format. Instead of going through all the date time hassles by operating on strings, it would be possible to defer any string / calendar representation up to the moment when it is really needed, e.g. for user display, or for date time arithmetic. Most SQL predicates work just the same on timestamp as on standard strings, e.g. = !=, and thus BETWEEN, IN, etc. On the other hand, there are UTC timestamps that cannot be represented via a unix timestamp, e.g. 31 December 1998 23:59:60 (a leap second). Thomas's suggestion with the string representation (ISO 8601, I assume?) looks interesting at first, although even then, you will probably need another internal representation that does not impair search performance. How does Apache Derby represent timestamp in storage? And while we're at it, to make things more interesting, have you ever considered supporting both the SQL standard TIMESTAMP WITHOUT TIMEZONE (your current implementation) and TIMESTAMP WITH TIMEZONE data types? :-) Am Dienstag, 6. Mai 2014 08:25:01 UTC+2 schrieb Noel Grandin: Hi Thomas, the problem you are talking about only exists when dealing with date values without time, like 1982-01-01, not for Timestamp values. We could store timestamps internally as a long value, defined in the same way as that System.currentTimeMillis is defined i.e. milliseconds since 1 Jan 1970 GMT. Then there are no daylight saving or midnight problems, because by definition it is unambiguous. See here for a fuller explanation: http://en.wikipedia.org/wiki/Unix_time http://en.wikipedia.org/wiki/Coordinated_Universal_Time Regards, Noel. On 2014-05-06 07:57, Thomas Mueller wrote: Hi, There are various problems when using java.util.Data / java.sql.Date / Time / Timestamp and java.util.Calendar, mainly because of the daylight time saving changes. For example, you can't assume a certain date (if you don't care about the time) is midnight, because in some timezones, for some days, midnight doesn't exist because it's the daylight time saving border. It's not a problem in most timezones, but it is in some. Regards, Thomas On Monday, May 5, 2014, Noel Grandin noelg...@gmail.com javascript:mailto: noelg...@gmail.com javascript: wrote: I'm curious - why do we not simply store date and time in UTC format? i.e. in milliseconds since 1 Jan 1970? That's pretty much a universal format these days, and then we can convert to whatever the local time zone is when we convert the value to string. If necessary, I could create an extra data type to represent time like this? I know I would use it, since that's how we represent all our data. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
On 2014-05-06 09:03, Lukas Eder wrote: And while we're at it, to make things more interesting, have you ever considered supporting both the SQL standard TIMESTAMP WITHOUT TIMEZONE (your current implementation) and TIMESTAMP WITH TIMEZONE data types? :-) I offered to implement it here: https://groups.google.com/d/msg/h2-database/rLakVH-CDXo/FL9bE_38_W0J But since nobody seemed willing to answer even basic questions about the feature, nothing happened. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
The good old free as in beer OSS consumer attitude :-) But let's not get mad about this. Let me try to answer those questions: Do you know (a) what the most common string representation of such a datatype is There are two candidates. ISO 8601 compliant or SQL standard compliant. The latter can be seen here: http://www.andrew.cmu.edu/user/shadow/sql/sql1992.txt timestamp literal ::= TIMESTAMP timestamp string timestamp string ::= quote date value space time value [ time zone interval ] quote date value ::= years value minus sign months value minus sign days value time value ::= hours value colon minutes value colon seconds value time zone interval ::= sign hours value colon minutes value For improved SQL compatibility, I suggest supporting the latter and optionally supporting ISO 8601 (through explicit functions) (b) how it is returned in a ResultSet, since there is no JDBC datatype for it This, unfortunately, is a complete mess :-) Most people probably bypass the Timestamp type and use Strings for deserialisation... (c) how it is passed into a PreparedStatement ... and for serialisation. However, I don't think that too many people have thought about these things well enough. Most people just try to avoid this issue by normalising everything to UTC and deferring timezone calculations as long as possible, e.g. until displaying a date to the UI. Or they're lucky enough and their software only runs in a single timezone, when they can just get away with defaults in 98% of the time. In any case, I don't think you will be able to expect a quick answer from your users. This is a tough topic. Cheers Lukas Am Dienstag, 6. Mai 2014 10:40:40 UTC+2 schrieb Noel Grandin: On 2014-05-06 09:03, Lukas Eder wrote: And while we're at it, to make things more interesting, have you ever considered supporting both the SQL standard TIMESTAMP WITHOUT TIMEZONE (your current implementation) and TIMESTAMP WITH TIMEZONE data types? :-) I offered to implement it here: https://groups.google.com/d/msg/h2-database/rLakVH-CDXo/FL9bE_38_W0J But since nobody seemed willing to answer even basic questions about the feature, nothing happened. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
Most people just try to avoid this issue by normalising everything to UTC and deferring timezone calculations as long as possible Yes that is correct. And guess what ... it works perfectly! The point where timezone becomes relevant is at the point when a timepoint is represented to user (format) and when user inputs a value into database (parse). I have created a scheduling program for tv station operating in multiple timezones and the way to make it work in H2 is to represent times as milliseconds since UE in UTC. The ability to deal with timezones in H2 is non-existent. The ability to deal with timezones in SQL is lacking seriously in functionality. The ability to deal with timezones in Java has been fairly good. The ability to deal with timezones in Java 8 seems to me very close to perfection. If you want to deal with timezones in database then I suggest you import the olsen data into database and put the timezone id into another column. And voilá you can do just about anything with that. If you think about it then TIMESTAMP WITH TIMEZONE is effectively 2 things (absolute time and timezone) put into 1 single type. The same thing can also be represented by two attributes. I just remember Thomas back in the day defending a position that when changing the timezone of the database the UTC value must change so that the local time stays the same. Go figure... - Rami -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
[h2] Question on a snippet from H2 Unit Testing code.
Hi,
I'm able to run the unit test in org.h2.test.unit.TestFileSystem.java
without any problems (in H2 version 1.3.174).
However, I'm unable to understand why the 2nd AssertThrows in the code
below (around the call to truncate) is working at all
private void testSimple(final String fsBase) throws Exception {
...
channel = FileUtils.open(fsBase + /test, r);
final byte[] test = new byte[1];
FileUtils.readFully(channel, ByteBuffer.wrap(test, 0, 1));
assertEquals(buffer, test);
final FileChannel fc = channel;
new AssertThrows(IOException.class) {
@Override
public void test() throws Exception {
fc.write(ByteBuffer.wrap(test, 0, 10));
}
};
new AssertThrows(IOException.class) {
@Override
public void test() throws Exception {
fc.truncate(10);
}
};
...
From the JDK documentation,
FileChannel.truncatehttp://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#truncate(long)
on
a readonly channel (or, a channel with a readonly underlying file) should
result in a NonWritableChannelException, and not an IOException. In the
following program that I wrote...
// size of /tmp/foo = 4 bytes
RandomAccessFile raf = new RandomAccessFile(/tmp/foo, r);
try {
java.nio.channels.FileChannel c = raf.getChannel();
c.truncate(1);
} catch(Exception e) {
e.printStackTrace();
}
... I do indeed get a NonWritableChannelException.
So, how come the 2nd AssertThrows around truncate in the H2 unit test is
working when it shouldn't?
Stumped,
/HS
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
Re: [h2] Question on a snippet from H2 Unit Testing code.
Because we have our own FileChannel implementation, we don't use the JDK one.
Or rather, we wrap the JDK NIO stuff in our own FileSystem layer, so that we
can implement custom FileSystem stuff.
Look at the FilePathDisk.java file, line 423.
It appears that we do not correctly mimic the JDK when handling non-writable channels, since we throw IOException
instead of NonWritableChannelException.
On 2014-05-06 15:25, hs wrote:
Hi,
I'm able to run the unit test in org.h2.test.unit.TestFileSystem.java without
any problems (in H2 version 1.3.174).
However, I'm unable to understand why the 2nd AssertThrows in the code below
(around the call to truncate) is working at
all
private void testSimple(final String fsBase) throws Exception {
...
channel = FileUtils.open(fsBase + /test, r);
final byte[] test = new byte[1];
FileUtils.readFully(channel, ByteBuffer.wrap(test, 0, 1));
assertEquals(buffer, test);
final FileChannel fc = channel;
new AssertThrows(IOException.class) {
@Override
public void test() throws Exception {
fc.write(ByteBuffer.wrap(test, 0, 10));
}
};
new AssertThrows(IOException.class) {
@Override
public void test() throws Exception {
fc.truncate(10);
}
};
...
From the JDK documentation, FileChannel.truncate
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#truncate(long)
on a readonly channel (or,
a channel with a readonly underlying file) should result in a
NonWritableChannelException, and not an IOException. In
the following program that I wrote...
// size of /tmp/foo = 4 bytes
RandomAccessFile raf = new RandomAccessFile(/tmp/foo, r);
try {
java.nio.channels.FileChannel c = raf.getChannel();
c.truncate(1);
} catch(Exception e) {
e.printStackTrace();
}
... I do indeed get a NonWritableChannelException.
So, how come the 2nd AssertThrows around truncate in the H2 unit test is
working when it shouldn't?
Stumped,
/HS
--
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
h2-database+unsubscr...@googlegroups.com
mailto:h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com
mailto:h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
[h2] Bug when using NOT IN on decimal columns?
Hi, is the following a bug or expected behaviour when using NOT IN to filter decimal columns when the list contains multiple numbers? *1. Define a table with a decimal column and a bigint column, and put in some data...* drop table if exists atable; create table atable ( adecimal decimal(21,6), aint bigint); insert into atable values(22,22), (33,33), (44,44); *2. Use IN and NOT IN to filter results on the decimal. The result when the list only has a single entry is as expected...* SELECT * FROM ATABLE where adecimal in (22); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# 22.0022(1 row, 1 ms) SELECT * FROM ATABLE where adecimal not in (22); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# 33.003344.0044(2 rows, 1 ms) *3. But it seems wrong when there is more than one number in the list* SELECT * FROM ATABLE where adecimal in (22,33); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf#(no rows, 1 ms) SELECT * FROM ATABLE where adecimal not in (22,33); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# 22.002233.003344.0044(3 rows, 9 ms) *4. Cross checking with integers gives the expected result...* SELECT * FROM ATABLE where aint in (22); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# 22.0022(1 row, 2 ms) SELECT * FROM ATABLE where aint not in (22); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# 33.003344.0044(2 rows, 1 ms) SELECT * FROM ATABLE where aint in (22,33); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# 22.002233.0033(2 rows, 1 ms) SELECT * FROM ATABLE where aint not in (22,33); ADECIMAL http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# AINT http://192.168.1.85:8082/query.do?jsessionid=479a5e0ac92a5da9e8a5e6ad074ac0cf# 44.0044(1 row, 1 ms) I'm on 1.3.175. Thanks, Ian. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
[h2] Re: Bug when using NOT IN on decimal columns?
Self-answered: it was a bug in 1.3.175, it works in 1.3.176. Thanks, Ian. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
[h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
Hi, H2 did store timestamps as UTC. Search for timezone in this group to see what problems this caused. With H2 version 1.4, this is no longer the case, and I believe this solves many issues. For example: Let's assume somebody in Elbonia (doesn't exist, I know) today stores a timestamp in the future, 2020-05-03 10:00:00, in H2. H2 would then convert that to UTC, let's say that's 2020-05-03 06:30:00. When storing that value, the rules are that this is during the daylight saving time of Elbonia. One year later, the Elbonia government decides to not use daylight saving time any longer, and they change the timezone by 30 minutes. Now, a user of H2 opens the database. Because of the changed rules, the conversion is no longer the same, and the displayed value is 2020-05-03 11:30:00, not any longer 10:00:00. I think that's weird. I would call it a bug. Because of such issues, H2 no longer stores UTC. The remaining issue is slow conversion between the internal format and java.sql.Date / Time / Timestamp, using java.util.Calendar. That can be solved. Once JDBC uses the Java 8 date time API, java.util.Calendar is no longer needed at all, and that's good. Daylight saving time changes is just one of the problems. Please note that timezone and daylight time saving information may change from time to time, even within the same region. Sometimes even retrospectively (for example, when storing a date in the future, and the rules change after that). When using java.util.Date or java.util.Calendar, there is usually a conversion between the local time and UTC needed, that means timezones come into play. If we store all timestamps in UTC, we need to convert to and from local timezone. The following can occur: if you open a database in a different timezone, the times (and dates) may be different. The same happens if the client doesn't have the same timezone as the server. Most people don't actually need to convert between timezones, they are just interested in the local time (as if no timezones and no daylight saving exists). I just remember Thomas back in the day defending a position that when changing the timezone of the database the UTC value must change so that the local time stays the same. Yes, the local time must stay the same, otherwise there are all kinds of problems. How the database stores the timestamp value is an implementation detail. H2 doesn't store UTC any longer. Most people probably bypass the Timestamp type and use Strings for deserialisation... In that case H2 doesn't use java.util.Calendar (any longer). H2 doesn't use java.util.Calender unless if the user uses java.sql.Date / Time / Timestamp. java.util.Calendar and Date does the timezone adjustments. With Java 8, with the new date and time API, those problems should be solved. Regards, Thomas On Tue, May 6, 2014 at 8:25 AM, Noel Grandin noelgran...@gmail.comjavascript:_e(%7B%7D,'cvml','noelgran...@gmail.com'); wrote: Hi Thomas, the problem you are talking about only exists when dealing with date values without time, like 1982-01-01, not for Timestamp values. We could store timestamps internally as a long value, defined in the same way as that System.currentTimeMillis is defined i.e. milliseconds since 1 Jan 1970 GMT. Then there are no daylight saving or midnight problems, because by definition it is unambiguous. See here for a fuller explanation: http://en.wikipedia.org/wiki/Unix_time http://en.wikipedia.org/wiki/Coordinated_Universal_Time Regards, Noel. On 2014-05-06 07:57, Thomas Mueller wrote: Hi, There are various problems when using java.util.Data / java.sql.Date / Time / Timestamp and java.util.Calendar, mainly because of the daylight time saving changes. For example, you can't assume a certain date (if you don't care about the time) is midnight, because in some timezones, for some days, midnight doesn't exist because it's the daylight time saving border. It's not a problem in most timezones, but it is in some. Regards, Thomas On Monday, May 5, 2014, Noel Grandin noelgran...@gmail.comjavascript:_e(%7B%7D,'cvml','noelgran...@gmail.com');mailto: noelgran...@gmail.comjavascript:_e(%7B%7D,'cvml','noelgran...@gmail.com'); wrote: I'm curious - why do we not simply store date and time in UTC format? i.e. in milliseconds since 1 Jan 1970? That's pretty much a universal format these days, and then we can convert to whatever the local time zone is when we convert the value to string. If necessary, I could create an extra data type to represent time like this? I know I would use it, since that's how we represent all our data. -- 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 h2-database+unsubscr...@googlegroups.comjavascript:_e(%7B%7D,'cvml','h2-database%2bunsubscr...@googlegroups.com');javascript:;. To
Re: [h2] 1.4 beta creates much bigger database file
Hi, Some initial results: you can shrink the database by running shutdown compact or shutdown defrag. Each time this is run, it shrinks a few MB (up to some point, of course). This works, but it's relatively slow. Now the task is to make it faster. There are two ways: shrink it fully to the minimum size, and shrink it incrementally (like now) but faster. I'm working on that now. Regards, Thomas On Tue, May 6, 2014 at 11:39 AM, Steve McLeod steve.mcl...@gmail.comwrote: Hi Thomas, I've sent you a private email with a link to the new database file, made with H2 1.4.178 Regards, Steve On Monday, 5 May 2014 07:46:16 UTC+2, Thomas Mueller wrote: Hi, The database file should shrink if you run shutdown defrag. The current compact algorithm is quite inefficient, that means the databases file is quite big on average. The highest priority is still to ensure it always works correctly, and when that's done I will work on more efficiently re-using disk space and specially compact the file faster when closing the database. Could you send me the new database file? It would be nice to have a real-world database file to test this. The last file you sent helped a lot, thanks to it I found some problems that completely prevented the file to shrink. Regards, Thomas On Sunday, May 4, 2014, Steve McLeod steve@gmail.com wrote: Hi Thomas, I tested the same large data import with H2 1.4.178, and there is no improvement over H2 1.4.177. Here are the file sizes, in both cases after the app has stopped: H2 1.3.176: pokercopilot.h2.db 301,669,352 bytes H2 1.4.178: pokercopilot.mv.db 1,023,037,440 bytes Let me know what I can do to help. Regards, Steve On Saturday, 19 April 2014 11:44:05 UTC+2, Steve McLeod wrote: Hi Thomas, Great! Glad I could help make your superb product even better. On Friday, 18 April 2014 21:38:27 UTC+2, Thomas Mueller wrote: Hi, Thanks a lot for the database! I know what the problem is now, but I couldn't fix it yet. The database file (pokercopilot2.mv.db) has about 181 MB of live data, the rest (about 78%) is not used. The mechanism to get rid of the unused space is not working as it should for this case (I think the problem is that b-tree nodes are not processed correctly). This will be fixed in the next release. Regards, Thomas On Fri, Apr 18, 2014 at 5:29 PM, Steve McLeod steve@gmail.comwrote: Hi Thomas, I've sent a link to file privately to your email address. Regards, Steve On Friday, 18 April 2014 14:04:37 UTC+2, Thomas Mueller wrote: Hi, Hm, that didn't help much. Could you send me the (compressed) database files please? If it's too big, what is the compressed size of the files? Regards, Thomas On Fri, Apr 18, 2014 at 1:07 PM, Steve McLeod steve@gmail.comwrote: Hi Thomas, Thanks for the suggestion. I tried adding ;retention_time=1000 to the URL, and this resulted in a small improvement. pokercopilot.h2.db 302,018,560 bytes pokercopilot.mv.db 999,120,896 bytes pokercopilot.mv.db with RETENTION_TIME=1000: 811,728,896 bytes These numbers all reflect a loading of data in a newly created database that consisted of roughly 2,400,000 INSERTS and UPDATES with plenty of SELECTS and almost no DELETES. After the loading was complete, I let the application keep running with the database open for a few minutes, then close the application and therefore the database. Here is the full JDBC url I'm using: jdbc:h2:/Users/steve/Library/Application Support/com.barbarysoftware.po kercopilot/database/pokercopilot;DATABASE_EVENT_LISTENER='co m.barbarysoftware.pokercopilot.database.DatabaseListener';COMPRESS_ LOB=DEFLATE;CACHE_SIZE=65536;RETENTION_TIME=1000 Let me know if there is anything else I can do to help diagnose this. Regards, Steve On Thursday, 17 April 2014 17:15:50 UTC+2, Thomas Muel -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send
[h2] Manual is not entirely accurate about ALTER TABLE statements
Hello, The manual is not entirely accurate about ALTER TABLE statements. Take this statement for instance: http://www.h2database.com/html/grammar.html#alter_table_alter_column The manual claims this syntax: - ALTER TABLE tableName ALTER COLUMN columnName When in fact it should be this syntax: - ALTER TABLE tableName ALTER [ COLUMN ] columnName I.e. the COLUMN keyword is optional. This is also true for DROP [ COLUMN ]. The ADD [ COLUMN ] statement, however, is correct. Cheers Lukas -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
2014-05-06 18:11 GMT+02:00 Thomas Mueller thomas.tom.muel...@gmail.com: Hi, H2 did store timestamps as UTC. Search for timezone in this group to see what problems this caused. I'm assuming you're talking about this thread: https://groups.google.com/d/msg/h2-database/O5mfM1iSSow/7QMDoGXndCIJ With H2 version 1.4, this is no longer the case, and I believe this solves many issues. For example: Let's assume somebody in Elbonia (doesn't exist, I know) today stores a timestamp in the future, 2020-05-03 10:00:00, in H2. H2 would then convert that to UTC, let's say that's 2020-05-03 06:30:00. When storing that value, the rules are that this is during the daylight saving time of Elbonia. One year later, the Elbonia government decides to not use daylight saving time any longer, and they change the timezone by 30 minutes. Now, a user of H2 opens the database. Because of the changed rules, the conversion is no longer the same, and the displayed value is 2020-05-03 11:30:00, not any longer 10:00:00. I think that's weird. I would call it a bug. Humm... I trade you your use-case against mine: That person in Elbonia calculated 2020-05-03 10:00:00 to be *exactly* (SQL standard syntax): CURRENT_TIMESTAMP() + '6-0' YEAR TO MONTH. So, TIMESTAMP + INTERVAL. Now, because of the above clever workaround, you go and (possibly) change their actual value towards what *would have been*: CURRENT_TIMESTAMP() + '6-0' YEAR TO MONTH + '0 01:30:00' DAY TO SECOND I can see your point, but I think the fix might have introduced quite a regression for some people who rely on TIMESTAMP being the equivalent of a unix timestamp, not a date-time literal - although, both representations have their eligibility. Now, I haven't thought this through to the end, but I still feel that we're moving into danger-zone with this change... What is your opinion regarding my example? -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
Let's assume somebody in Elbonia (doesn't exist, I know) today stores a timestamp in the future, 2020-05-03 10:00:00, in H2. H2 would then convert that to UTC, let's say that's 2020-05-03 06:30:00. When storing that value, the rules are that this is during the daylight saving time of Elbonia. One year later, the Elbonia government decides to not use daylight saving time any longer, and they change the timezone by 30 minutes. Now, a user of H2 opens the database. Because of the changed rules, the conversion is no longer the same, and the displayed value is 2020-05-03 11:30:00, not any longer 10:00:00. I think that's weird. I would call it a bug. Let's go over your example carefully. A string 2020-05-03 10:00:00 is inputted and interpreted in the timezone of Elbonia. I would rather describe the result of parsing this string as a long say 234000L (NB. I just typed a random integer here) This is completely unequivocal (if we ignore the occasional leap seconds). It is milliseconds since UE in UTC. This will never change. It does not matter if Elbonia had at that point DST or what. The transformation from string 2020-05-03 10:00:00 to long 234000L was completely determined by the Timezone information (say implementation of java.util.TimeZone) at the time. If it turns out later that the timezone in year 2020 was different and there was no DST in effect or maybe Elbonia decided to change their offset completely then it is true that the conversion was done with inaccurate information. Therefore IANA's timezone database (olsen) has also historical information going back maybe in some cases even hundred years. SimpleTimeZone does not use historical info but one can create easily enough a TimeZone implementation that utilizes that information. Going further into history with accurate timezone information is a fool's game because most people did not put so much effort into accurate tracking of time say 500 years ago when Europe slowly switched to Gregorian calendar. And obviously going into future with timezone information is unpredictable. But I defer let's deal with your use case. Usually when someone creates a temporal value far into future it is a date not an exact point in time (especially not in some timezone because no one knows yet what the timezone will be in the future). If someone wishes to point to an exact point in time in the future then that someone would use UTC so as to get rid of the obscurity. Usually temporal values made into future are dates (meaning the time component is omitted). And dates never have a timezone. Or if you want to talk of a date in a timezone you need 2 timepoints, the start and the end of the date in that specific timezone. So all date and time types should never have anything to do with timezones. But timestamps MUST have a timezone associated so that we can represent them as a string unequivocally. To sum it up: In your use case the user should input his future timepoint in UTC so that it would be unequivocal and accurate. If he wants to point to an undetermined timepoint in the future (a timepoint that will be in Elbonian timezone 2020-05-03 10:00:00 also in year 2020) then for those values I would suggest using the string type and just storing the string. And maybe storing in another column the name of timezone that is associated with this timepoint. And then when year 2020 comes around and he knows what the Elbonian timezone is at that time then he could parse the timepoint into milliseconds in UTC. Storing timepoints in a coordinate system that is fixed makes the interpretation of data so much simpler. - Rami -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Problem with JDBC Url (h2 server mode)
Hi I am using windows 8.1 I don't use basedir stacktrace from webinterface A file path that is implicitly relative to the current working directory is not allowed in the database URL jdbc:h2:tcp://localhost//data. Use an absolute path, ~/name, ./name, or the baseDir setting instead. [90011-178]http://192.168.178.22:8082/login.do?jsessionid=1f11c71bfd1d3c8e3702e85cef26f179#90011/90011 (Hilfe)http://h2database.com/javadoc/org/h2/constant/ErrorCode.html#c90011 org.h2.jdbc.JdbcSQLException: A file path that is implicitly relative to the current working directory is not allowed in the database URL jdbc:h2:tcp://localhost//data. Use an absolute path, ~/name, ./name, or the baseDir setting instead. [90011-178] at org.h2.message.DbException.getJdbcSQLException(DbException.java:344http://h2database.com/html/source.html?file=org/h2/message/DbException.javaline=344build=178) at org.h2.message.DbException.get(DbException.java:178http://h2database.com/html/source.html?file=org/h2/message/DbException.javaline=178build=178) at org.h2.message.DbException.get(DbException.java:154http://h2database.com/html/source.html?file=org/h2/message/DbException.javaline=154build=178) at org.h2.engine.ConnectionInfo.getName(ConnectionInfo.java:392http://h2database.com/html/source.html?file=org/h2/engine/ConnectionInfo.javaline=392build=178) at org.h2.engine.Engine.openSession(Engine.java:42http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=42build=178) at org.h2.engine.Engine.openSession(Engine.java:164http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=164build=178) at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=142build=178) at org.h2.engine.Engine.createSession(Engine.java:125http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=125build=178) at org.h2.server.TcpServerThread.run(TcpServerThread.java:150http://h2database.com/html/source.html?file=org/h2/server/TcpServerThread.javaline=150build=178) at java.lang.Thread.run(Unknown Source) at org.h2.engine.SessionRemote.done(SessionRemote.java:610http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=610build=178) at org.h2.engine.SessionRemote.initTransfer(SessionRemote.java:129http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=129build=178) at org.h2.engine.SessionRemote.connectServer(SessionRemote.java:434http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=434build=178) at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:315http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=315build=178) at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:107http://h2database.com/html/source.html?file=org/h2/jdbc/JdbcConnection.javaline=107build=178) at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:91http://h2database.com/html/source.html?file=org/h2/jdbc/JdbcConnection.javaline=91build=178) at org.h2.Driver.connect(Driver.java:74http://h2database.com/html/source.html?file=org/h2/Driver.javaline=74build=178) at org.h2.server.web.WebServer.getConnection(WebServer.java:684http://h2database.com/html/source.html?file=org/h2/server/web/WebServer.javaline=684build=178) at org.h2.server.web.WebApp.login(WebApp.java:958http://h2database.com/html/source.html?file=org/h2/server/web/WebApp.javaline=958build=178) at org.h2.server.web.WebApp.process(WebApp.java:212http://h2database.com/html/source.html?file=org/h2/server/web/WebApp.javaline=212build=178) at org.h2.server.web.WebApp.processRequest(WebApp.java:171http://h2database.com/html/source.html?file=org/h2/server/web/WebApp.javaline=171build=178) at org.h2.server.web.WebThread.process(WebThread.java:138http://h2database.com/html/source.html?file=org/h2/server/web/WebThread.javaline=138build=178) at org.h2.server.web.WebThread.run(WebThread.java:94http://h2database.com/html/source.html?file=org/h2/server/web/WebThread.javaline=94build=178) at java.lang.Thread.run(Unknown Source) Iam using older version now. Maybe switching to jdbc:h2:tcp://localhost//~/data. Am Montag, 5. Mai 2014 07:46:15 UTC+2 schrieb Thomas Mueller: Hi, I can't reproduce the problem with your database URL. Do you use Windows? Do you use the baseDir setting? Could you post the complete error message including all stack traces please? Regards, Thomas On Sunday, May 4, 2014, Thomas Mueller thomas.to...@gmail.comjavascript: wrote: Hi, Hm, I think your url should work, as it's absolute due to double slash (database in the root directory). I will investigate. Regards, Thomas On Saturday, May 3, 2014, Stefan Beigel beigel.ste...@gmail.com wrote: Hi guys Getting this
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
Hi, I'm not quite sure, but you seem to assume people are interested in what time it is UTC. But I believe in 99.9% of the case, people are interested in local date and time only. In the Java 8 DateTime API, I assume most people will use LocalDateTime, LocalDate, LocalTime, and not ZonedDateTime http://docs.oracle.com/javase/8/docs/api/index.html?java/time/chrono/ChronoLocalDate.html Where possible, it is recommended to use a simpler class without a time-zone. The widespread use of time-zones tends to add considerable complexity to an application. Storing timepoints in acoordinate system that is fixed makes the interpretation of data so much simpler. No. The opposite is true: due to the timezone conversion rules, it makes things unnecessarily complicated, brittle, and can result in big trouble if the timezone rules change. Which they do regularly. Regards, Thomas On Tue, May 6, 2014 at 7:43 PM, Rami Ojares rami.oja...@gmail.com wrote: Let's assume somebody in Elbonia (doesn't exist, I know) today stores a timestamp in the future, 2020-05-03 10:00:00, in H2. H2 would then convert that to UTC, let's say that's 2020-05-03 06:30:00. When storing that value, the rules are that this is during the daylight saving time of Elbonia. One year later, the Elbonia government decides to not use daylight saving time any longer, and they change the timezone by 30 minutes. Now, a user of H2 opens the database. Because of the changed rules, the conversion is no longer the same, and the displayed value is 2020-05-03 11:30:00, not any longer 10:00:00. I think that's weird. I would call it a bug. Let's go over your example carefully. A string 2020-05-03 10:00:00 is inputted and interpreted in the timezone of Elbonia. I would rather describe the result of parsing this string as a long say 234000L (NB. I just typed a random integer here) This is completely unequivocal (if we ignore the occasional leap seconds). It is milliseconds since UE in UTC. This will never change. It does not matter if Elbonia had at that point DST or what. The transformation from string 2020-05-03 10:00:00 to long 234000L was completely determined by the Timezone information (say implementation of java.util.TimeZone) at the time. If it turns out later that the timezone in year 2020 was different and there was no DST in effect or maybe Elbonia decided to change their offset completely then it is true that the conversion was done with inaccurate information. Therefore IANA's timezone database (olsen) has also historical information going back maybe in some cases even hundred years. SimpleTimeZone does not use historical info but one can create easily enough a TimeZone implementation that utilizes that information. Going further into history with accurate timezone information is a fool's game because most people did not put so much effort into accurate tracking of time say 500 years ago when Europe slowly switched to Gregorian calendar. And obviously going into future with timezone information is unpredictable. But I defer let's deal with your use case. Usually when someone creates a temporal value far into future it is a date not an exact point in time (especially not in some timezone because no one knows yet what the timezone will be in the future). If someone wishes to point to an exact point in time in the future then that someone would use UTC so as to get rid of the obscurity. Usually temporal values made into future are dates (meaning the time component is omitted). And dates never have a timezone. Or if you want to talk of a date in a timezone you need 2 timepoints, the start and the end of the date in that specific timezone. So all date and time types should never have anything to do with timezones. But timestamps MUST have a timezone associated so that we can represent them as a string unequivocally. To sum it up: In your use case the user should input his future timepoint in UTC so that it would be unequivocal and accurate. If he wants to point to an undetermined timepoint in the future (a timepoint that will be in Elbonian timezone 2020-05-03 10:00:00 also in year 2020) then for those values I would suggest using the string type and just storing the string. And maybe storing in another column the name of timezone that is associated with this timepoint. And then when year 2020 comes around and he knows what the Elbonian timezone is at that time then he could parse the timepoint into milliseconds in UTC. Storing timepoints in a coordinate system that is fixed makes the interpretation of data so much simpler. - Rami -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at
Re: [h2] Excessive amount of time spent in org.h2.util.DateTimeUtils.getTimeTry()
Well, frankly I am ok with any approach since I already use succesfully the biggint type and custom made functions for all my temporal needs. I merely wanted to give my thoughts as a service to the community. And completely respect your views as the owner of this project. Sincerely, Rami -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
[h2] How to Create 2 H2 databases with the Same Name
Hello H2 community, Here is a quick question about H2. Is it possible to create 2 H2 databases with the same database names in memory? Let me give a quick introduction to my project. I am required to write integration tests (I use Spring/Hibernate). In order to fulfill the tests, I need two exactly identical databases (schema and data). My boss requested me not to create a H2 database on my computer's hard driver. What he really liked was in-memory databases. However, how can I create two in-memory databases with same names? Is there any way to distinguish each other? Thanks so much Gilbert -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Problem with JDBC Url (h2 server mode)
Hi, I found the problem, it will be fixed in the next release. It seems to be happening only in Windows by the way. Regards, Thomas On Tuesday, May 6, 2014, Stefan Beigel beigel.ste...@gmail.com wrote: Hi I am using windows 8.1 I don't use basedir stacktrace from webinterface A file path that is implicitly relative to the current working directory is not allowed in the database URL jdbc:h2:tcp://localhost//data. Use an absolute path, ~/name, ./name, or the baseDir setting instead. [90011-178]http://192.168.178.22:8082/login.do?jsessionid=1f11c71bfd1d3c8e3702e85cef26f179#90011/90011 (Hilfe)http://h2database.com/javadoc/org/h2/constant/ErrorCode.html#c90011 org.h2.jdbc.JdbcSQLException: A file path that is implicitly relative to the current working directory is not allowed in the database URL jdbc:h2:tcp://localhost//data. Use an absolute path, ~/name, ./name, or the baseDir setting instead. [90011-178] at org.h2.message.DbException.getJdbcSQLException(DbException.java:344http://h2database.com/html/source.html?file=org/h2/message/DbException.javaline=344build=178) at org.h2.message.DbException.get(DbException.java:178http://h2database.com/html/source.html?file=org/h2/message/DbException.javaline=178build=178) at org.h2.message.DbException.get(DbException.java:154http://h2database.com/html/source.html?file=org/h2/message/DbException.javaline=154build=178) at org.h2.engine.ConnectionInfo.getName(ConnectionInfo.java:392http://h2database.com/html/source.html?file=org/h2/engine/ConnectionInfo.javaline=392build=178) at org.h2.engine.Engine.openSession(Engine.java:42http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=42build=178) at org.h2.engine.Engine.openSession(Engine.java:164http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=164build=178) at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=142build=178) at org.h2.engine.Engine.createSession(Engine.java:125http://h2database.com/html/source.html?file=org/h2/engine/Engine.javaline=125build=178) at org.h2.server.TcpServerThread.run(TcpServerThread.java:150http://h2database.com/html/source.html?file=org/h2/server/TcpServerThread.javaline=150build=178) at java.lang.Thread.run(Unknown Source) at org.h2.engine.SessionRemote.done(SessionRemote.java:610http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=610build=178) at org.h2.engine.SessionRemote.initTransfer(SessionRemote.java:129http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=129build=178) at org.h2.engine.SessionRemote.connectServer(SessionRemote.java:434http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=434build=178) at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:315http://h2database.com/html/source.html?file=org/h2/engine/SessionRemote.javaline=315build=178) at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:107http://h2database.com/html/source.html?file=org/h2/jdbc/JdbcConnection.javaline=107build=178) at org.h2.jdbc.JdbcConnection.init(JdbcConnection.java:91http://h2database.com/html/source.html?file=org/h2/jdbc/JdbcConnection.javaline=91build=178) at org.h2.Driver.connect(Driver.java:74http://h2database.com/html/source.html?file=org/h2/Driver.javaline=74build=178) at org.h2.server.web.WebServer.getConnection(WebServer.java:684http://h2database.com/html/source.html?file=org/h2/server/web/WebServer.javaline=684build=178) at org.h2.server.web.WebApp.login(WebApp.java:958http://h2database.com/html/source.html?file=org/h2/server/web/WebApp.javaline=958build=178) at org.h2.server.web.WebApp.process(WebApp.java:212http://h2database.com/html/source.html?file=org/h2/server/web/WebApp.javaline=212build=178) at org.h2.server.web.WebApp.processRequest(WebApp.java:171http://h2database.com/html/source.html?file=org/h2/server/web/WebApp.javaline=171build=178) at org.h2.server.web.WebThread.process(WebThread.java:138http://h2database.com/html/source.html?file=org/h2/server/web/WebThread.javaline=138build=178) at org.h2.server.web.WebThread.run(WebThread.java:94http://h2database.com/html/source.html?file=org/h2/server/web/WebThread.javaline=94build=178) at java.lang.Thread.run(Unknown Source) Iam using older version now. Maybe switching to jdbc:h2:tcp://localhost//~/data. Am Montag, 5. Mai 2014 07:46:15 UTC+2 schrieb Thomas Mueller: Hi, I can't reproduce the problem with your database URL. Do you use Windows? Do you use the baseDir setting? Could you post the complete error message including all stack traces please? Regards, Thomas On Sunday, May 4, 2014, Thomas Mueller thomas.to...@gmail.com wrote: Hi, Hm, I think your url should work, as it's absolute
Re: [h2] Manual is not entirely accurate about ALTER TABLE statements
Hi, In order to simplify the documentation, currently, not all variants of the grammar are documented, only those that are recommended (that's a fuzzy description, I know). That is, if people write new code, they should use the documented grammar, and not rely on the undocumented features. The undocumented features are for compatibility with other databases. So, I wonder whether it is important to document that column is optional in those cases. Is it optional in the ANSI SQL standard? Regards, Thomas On Tuesday, May 6, 2014, Lukas Eder lukas.e...@gmail.com wrote: Hello, The manual is not entirely accurate about ALTER TABLE statements. Take this statement for instance: http://www.h2database.com/html/grammar.html#alter_table_alter_column The manual claims this syntax: - ALTER TABLE tableName ALTER COLUMN columnName When in fact it should be this syntax: - ALTER TABLE tableName ALTER [ COLUMN ] columnName I.e. the COLUMN keyword is optional. This is also true for DROP [ COLUMN ]. The ADD [ COLUMN ] statement, however, is correct. Cheers Lukas -- 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 h2-database+unsubscr...@googlegroups.comjavascript:_e(%7B%7D,'cvml','h2-database%2bunsubscr...@googlegroups.com'); . To post to this group, send email to h2-database@googlegroups.comjavascript:_e(%7B%7D,'cvml','h2-database@googlegroups.com'); . Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] How to Create 2 H2 databases with the Same Name
Hi, I don't understand why the database would need to have the same name. You can have two databases with different names, but the same data and schema. Why the same name? Are you sure you need two databases? Why not run the tests against the same database? Regards, Thomas On Tuesday, May 6, 2014, gilber...@gmail.com wrote: Hello H2 community, Here is a quick question about H2. Is it possible to create 2 H2 databases with the same database names in memory? Let me give a quick introduction to my project. I am required to write integration tests (I use Spring/Hibernate). In order to fulfill the tests, I need two exactly identical databases (schema and data). My boss requested me not to create a H2 database on my computer's hard driver. What he really liked was in-memory databases. However, how can I create two in-memory databases with same names? Is there any way to distinguish each other? Thanks so much Gilbert -- 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 h2-database+unsubscr...@googlegroups.comjavascript:_e(%7B%7D,'cvml','h2-database%2bunsubscr...@googlegroups.com'); . To post to this group, send email to h2-database@googlegroups.comjavascript:_e(%7B%7D,'cvml','h2-database@googlegroups.com'); . Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout. -- 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 h2-database+unsubscr...@googlegroups.com. To post to this group, send email to h2-database@googlegroups.com. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
Re: [h2] Question on a snippet from H2 Unit Testing code.
Hi,
It appears that we do not correctly mimic the JDK when handling
non-writable channels, since we throw IOException instead of
NonWritableChannelException.
That's true. I think in old versions of the JDK javadoc (actually, still in
the Eclipse popup documentation, strangely), only IOException was
documented, so I assumed it's an implementation bug. But
NonWritableChannelException is documented in the online javadocs, so I
think we should change the implementation to throw and expect a
NonWritableChannelException.
Regrads,
Thomas
On 2014-05-06 15:25, hs wrote:
Hi,
I'm able to run the unit test in org.h2.test.unit.TestFileSystem.java
without any problems (in H2 version 1.3.174).
However, I'm unable to understand why the 2nd AssertThrows in the code
below (around the call to truncate) is working at
all
private void testSimple(final String fsBase) throws Exception {
...
channel = FileUtils.open(fsBase + /test, r);
final byte[] test = new byte[1];
FileUtils.readFully(channel, ByteBuffer.wrap(test, 0, 1));
assertEquals(buffer, test);
final FileChannel fc = channel;
new AssertThrows(IOException.class) {
@Override
public void test() throws Exception {
fc.write(ByteBuffer.wrap(test, 0, 10));
}
};
new AssertThrows(IOException.class) {
@Override
public void test() throws Exception {
fc.truncate(10);
}
};
...
From the JDK documentation, FileChannel.truncate
http://docs.oracle.com/javase/7/docs/api/java/nio/
channels/FileChannel.html#truncate(long) on a readonly channel (or,
a channel with a readonly underlying file) should result in a
NonWritableChannelException, and not an IOException. In
the following program that I wrote...
// size of /tmp/foo = 4 bytes
RandomAccessFile raf = new RandomAccessFile(/tmp/foo, r);
try {
java.nio.channels.FileChannel c = raf.getChannel();
c.truncate(1);
} catch(Exception e) {
e.printStackTrace();
}
... I do indeed get a NonWritableChannelException.
So, how come the 2nd AssertThrows around truncate in the H2 unit test is
working when it shouldn't?
Stumped,
/HS
--
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
h2-database+unsubscr...@googlegroups.com mailto:
h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.commailto:
h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
