Re: [h2] H2: getGeneratedKeys returns only the last id limitation.

Ok. This feature is really very important for me. I will try to implement it myself. Could you just point me where I should look at in order not to look through all the code. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from

Re: [h2] MVStore with MVCC performance degradation

Hi, I would be interested in the database URL(s) you use (any options you use), and a few full thread dumps (maybe 100 or so). I usually get full thread dumps like this: jps -l (to get the process id) jstack -l PID | gzip >> threadDumps.txt You can get the thread dumps in a loop (with a delay of

[h2] Re: "Order by" is broken in 1.4.186 (2015-03-02), Beta

I'm seeing a similar problem, but not in all cases. 1.4.185 is fine. 1.4.186 and 1.4.187 fail a specific test, but not all tests. Did you ever resolve this issue? If so, what was the fix? Thanks, David On Monday, April 6, 2015 at 11:39:22 PM UTC-4, Serge Korn wrote: > > Hi, > > Since upgrading

Re: [h2] H2: getGeneratedKeys returns only the last id limitation.

Hi, With autocommit disabled, I think there should be no gaps, but now thinking about it again I'm not completely sure. It's probably best if you test it. Regards, Thomas On Friday, June 12, 2015, iJava wrote: > Ok. Will the following code guarantee 100% that there won't be any id gaps > whe

[h2] MVStore with MVCC performance degradation

We are testing the latest H2 version (from a recent nightly build, actually) in place of a rather ancient but serviceable version 1.2. We are seeing performance degradation of at least a factor of 6. We have suites of test. I can supply you with comparison timings, but for example a suite th

Re: [h2] H2: getGeneratedKeys returns only the last id limitation.

Ok. Will the following code guarantee 100% that there won't be any id gaps when H2 is server (there are other clients)? Connection conn= getting connection from pool conn.setAutoCommit(false); ps = conn.prepareStatement(query,Statement.RETURN_GENERATED_KEYS)

Re: [h2] H2: getGeneratedKeys returns only the last id limitation.

Hi, Hm, I think you are right. With autocommit enabled, I think there could be gaps. Of course there are workarounds, for example using a single statement of the form "insert into ... values (?, ?), (?, ?), (?, ?)". For H2, that would be faster than using batch inserts, and it is one transaction.

Re: [h2] H2: getGeneratedKeys returns only the last id limitation.

Thank you very much for your answer. Yes, I insert without gaps. Yes, I can calculate from last ID and and in reverse order to find out all the previous id. However, this solution will work only with two conditions: 1)When H2 is a server and there are other clients who make inserts but my mult

Re: [h2] H2: getGeneratedKeys returns only the last id limitation.

Hi, Sorry, there is currently no plan to support this. It does everything I need except one very basic, very important thing - > when using multiple insert > I assume multiple inserts would generate incrementing ids, without gaps? If yes, you could calculate the old ids from the latest. If not,

Re: [h2] How to reproduce the Explain command output programmatically?

Hi, I would probably use org.h2.table.Table, and specially org.h2.index.Index. That way, you can ensure there are conditions on all the required columns. I don't think using the plan, or another internal API is needed. Regards, Thomas On Friday, June 12, 2015, Nicolas Fortin (OrbisGIS) wrote:

Re: [h2] How to reproduce the Explain command output programmatically?

Hi, I don't understand all but You can track queries if you are using the DatabaseEventListener: https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/api/DatabaseEventListener.java Generally we use connection url to set a event listener however you may be able to force it us