[h2] Re: changing sequence cache

[Brian Craft]

175 is working for me. It has "alter sequence .. cache", and it reads the 
tables built with 171. It's only 176 which doesn't like the tables.


On Wednesday, May 28, 2014 6:28:59 PM UTC-7, Brian Craft wrote:
>
> With much digging through the archives, I found this example for setting 
> the sequence when creating a table:
>
> CREATE SEQUENCE TESTSEQ;
> CREATE TABLE TEST(ID INT DEFAULT NEXT VALUE FOR TESTSEQ PRIMARY KEY);
>
> However I still have no migration strategy due to the problems moving from 
> 171 to 176.
>
> On Wednesday, May 28, 2014 3:13:46 PM UTC-7, Brian Craft wrote:
>>
>> How can I set the cache for a primary key sequence? I haven't found a way 
>> to specify the cache when creating the column. Also haven't found a way to 
>> specify the sequence for the column, so I can't create the sequence with 
>> the right cache and then create a column that uses it.
>>
>> Also, the "alter sequence .. cache" command isn't working. I suspect it 
>> is a recent addition. I will try updating.
>>
>>

-- 
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: changing sequence cache

[Brian Craft]

With much digging through the archives, I found this example for setting 
the sequence when creating a table:

CREATE SEQUENCE TESTSEQ;
CREATE TABLE TEST(ID INT DEFAULT NEXT VALUE FOR TESTSEQ PRIMARY KEY);

However I still have no migration strategy due to the problems moving from 
171 to 176.

On Wednesday, May 28, 2014 3:13:46 PM UTC-7, Brian Craft wrote:
>
> How can I set the cache for a primary key sequence? I haven't found a way 
> to specify the cache when creating the column. Also haven't found a way to 
> specify the sequence for the column, so I can't create the sequence with 
> the right cache and then create a column that uses it.
>
> Also, the "alter sequence .. cache" command isn't working. I suspect it is 
> a recent addition. I will try updating.
>
>

-- 
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: changing sequence cache

[Brian Craft]

Checking if I can change the sequence cache by updating the 
information_schema table, in 171. Doesn't seem to work:

update information_schema.sequences set cache = 2001 where 
sequence_name='SYSTEM_SEQUENCE_91459F04_54A2_41A6_8BA7_FF4BBFF4EFBD'

throws this error:

JdbcSQLException Feature not supported: "META";



On Wednesday, May 28, 2014 5:50:12 PM UTC-7, Brian Craft wrote:
>
> I updated from 1.3.171 to 1.3.176 to pick up the "alter sequence .. cache" 
> command. After changing the cache, on the next start of the app h2 is 
> unable to connect to the db. It fills the trace file with this:
>
> 05-28 17:27:33 database: ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT 
> PUBLIC.CONSTRAINT_8D2C2 FOREIGN KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) 
> NOCHECK
> org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: 
> "PRIMARY KEY ON .PAGE_INDEX"; SQL statement:
> ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT PUBLIC.CONSTRAINT_8D2C2 FOREIGN 
> KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) NOCHECK [23505-176]
> 05-28 17:27:33 database: ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT 
> PUBLIC.CONSTRAINT_8D2C2 FOREIGN KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) 
> NOCHECK
> org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: 
> "PRIMARY KEY ON .PAGE_INDEX"; SQL statement:
> ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT PUBLIC.CONSTRAINT_8D2C2 FOREIGN 
> KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) NOCHECK [23505-176]
>
> and so on for several pages.
>
> Backing off to 171 allows it to connect again.
>
> Not sure where to go from here. 
>
> On Wednesday, May 28, 2014 3:13:46 PM UTC-7, Brian Craft wrote:
>>
>> How can I set the cache for a primary key sequence? I haven't found a way 
>> to specify the cache when creating the column. Also haven't found a way to 
>> specify the sequence for the column, so I can't create the sequence with 
>> the right cache and then create a column that uses it.
>>
>> Also, the "alter sequence .. cache" command isn't working. I suspect it 
>> is a recent addition. I will try updating.
>>
>>

-- 
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: changing sequence cache

[Brian Craft]

I updated from 1.3.171 to 1.3.176 to pick up the "alter sequence .. cache" 
command. After changing the cache, on the next start of the app h2 is 
unable to connect to the db. It fills the trace file with this:

05-28 17:27:33 database: ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT 
PUBLIC.CONSTRAINT_8D2C2 FOREIGN KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) 
NOCHECK
org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: 
"PRIMARY KEY ON .PAGE_INDEX"; SQL statement:
ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT PUBLIC.CONSTRAINT_8D2C2 FOREIGN 
KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) NOCHECK [23505-176]
05-28 17:27:33 database: ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT 
PUBLIC.CONSTRAINT_8D2C2 FOREIGN KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) 
NOCHECK
org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: 
"PRIMARY KEY ON .PAGE_INDEX"; SQL statement:
ALTER TABLE PUBLIC.PROBES ADD CONSTRAINT PUBLIC.CONSTRAINT_8D2C2 FOREIGN 
KEY(EID) REFERENCES PUBLIC.EXPERIMENTS(ID) NOCHECK [23505-176]

and so on for several pages.

Backing off to 171 allows it to connect again.

Not sure where to go from here. 

On Wednesday, May 28, 2014 3:13:46 PM UTC-7, Brian Craft wrote:
>
> How can I set the cache for a primary key sequence? I haven't found a way 
> to specify the cache when creating the column. Also haven't found a way to 
> specify the sequence for the column, so I can't create the sequence with 
> the right cache and then create a column that uses it.
>
> Also, the "alter sequence .. cache" command isn't working. I suspect it is 
> a recent addition. I will try updating.
>
>

-- 
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] changing sequence cache

[Brian Craft]

How can I set the cache for a primary key sequence? I haven't found a way 
to specify the cache when creating the column. Also haven't found a way to 
specify the sequence for the column, so I can't create the sequence with 
the right cache and then create a column that uses it.

Also, the "alter sequence .. cache" command isn't working. I suspect it is 
a recent addition. I will try updating.

-- 
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] inserrting/updating CLOB using prepared statements

[Adam McMahon]

Noel,

Thanks for the feedback. My Strings are already in memory, because they are 
sent via a web post.  So, setStringa and setCharacterStream do not affect 
how the data is stored in H2, but the steam allows you to prevent having 
the whole thing in memory at insertion time, but after that it is all the 
same.  correct?

Thanks,
-Adam

On Wednesday, May 28, 2014 10:04:23 AM UTC-4, Noel Grandin wrote:
>
>
>
> On 2014-05-27 17:24, Adam McMahon wrote: 
> > 
> > I would like to use the Clob data type for my variable length strings 
> that average around 300 characters.   I see in the 
> > doc that I should use " |PreparedStatement.setCharacterStream| to store 
> values".   Instead I am simply using 
> > PreparedStatment.setString().   This seems to work.  Is there any 
> advantage to using setCharacterStream?  This may be 
> > more of a JDBC question than an H2 question, but I thought I would start 
> in this group with the question. 
> > 
>
> At that size it makes no difference. 
>
> setCharacterStream() is there for the case where the CLOB is large enough 
> that you don't want to keep the whole thing in 
> memory at once. 
>

-- 
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] Persistent console history

[Martin Grajcar]

On Wed, May 28, 2014 at 8:13 PM, Thomas Mueller <
thomas.tom.muel...@gmail.com> wrote:

> Hi,
>
> The H2 Console tool stores the settings in a file called
> ".h2.server.properties" in the current user home directory
> (Constants.SERVER_PROPERTIES_NAME).
>

I'd also prefer Properties to Preferences, as Preferences are rather
limited and rather unreadable (except for XML fans). The only disadvantage
is that the file can get rather big which makes finding thing to set by
hand a bit harder.


> If the history is stored, it should probably be stored there. But I'm not
> sure whether it should be stored; it would be a security problem because
> the history would be shared across all users I guess.
>

You wrote that it's stored in the *user* home directory and the file is
readable by the owner only and that's IMHO about all what can be done for
security (encryption by a key stored in a program is pointless and entering
the key is too much hassle for such a feature).

But I can see that it could be a problem for someone, so I'd make it
optional.


> So the history should probably be split into groups, for example by IP
> address of the client.
>

That's a bit counter-productive, as I'm doing the same things both locally
and on the server, so I can use the same history for both. But for someone
it may be better. Concerning security, I'm unsure if it helps.

Regards, Martin.

-- 
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] Persistent console history

[Thomas Mueller]

Hi,

The H2 Console tool stores the settings in a file called
".h2.server.properties" in the current user home directory
(Constants.SERVER_PROPERTIES_NAME). If the history is stored, it should
probably be stored there. But I'm not sure whether it should be stored; it
would be a security problem because the history would be shared across all
users I guess. So the history should probably be split into groups, for
example by IP address of the client.

Regards,
Thomas



On Wed, May 28, 2014 at 6:07 PM, Martin Grajcar wrote:

> Thank you for the fast answer. I guess I can do it, the only problem are
> the Preferences limitation. There's no way to store WebSession.MAX_HISTORY
> = 1000 entries as a single value as there's the Preferences.MAX_VALUE_LENGTH
> = 8*1024 limit. Using multiple values gets complicated because of
> deletions of duplicates. 1. It could be done trivially by always storing
> the whole list, but this is ugly and could possibly take non-negligible
> amount of time due to quickly filling FileSystemPreferences.changeLog).
> Or not; the thing is rather complicated. 2. Doing some smart node reuse and
> re-linking is rather complicated, but doable. 3. Limiting the stored
> history to 8 KB would suffice for me.
>
> So there are three possibilities, which one do you prefer?
>
> Regards, Martin.
>
>
> On Wed, May 28, 2014 at 4:36 PM, Noel Grandin wrote:
>
>> Sounds reasonable to me.
>>
>> The code you want lives in
>> src\main\org\h2\server\web\WebApp.java
>> src\main\org\h2\server\web\WebSession.java
>>
>> search for "@history" and follow the code.
>>
>> I suspect that the easiest option would be to have the console webapp
>> store the history data using the java.util.prefs.Preferences stuff.
>>
>>
>> On 2014-05-28 16:18, Martin Grajcar wrote:
>>
>>> The console history is a nice feature, but sometimes I get kicked out
>>> and have to log in again and the history is gone.
>>>
>>> I don't know exactly when and why I get kicked out. Is there something I
>>> could do about it?
>>>
>>> I didn't mean the persistency literarily, it's just that I'd love if it
>>> could survive such events. Using cookies or
>>> browser local storage or whatever... I guess I could do it myself, but
>>> first I'd like to know your opinion. Does it make
>>> sense? Where to start?
>>>
>>
>> --
>> 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 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] mvcc, long-running insert from csv

[Brian Craft]

Thanks!

Does MULTI_THREADED only help outside of a transaction? During a 
transaction the table will still be locked.

On Tuesday, May 27, 2014 10:47:46 PM UTC-7, Kartweel wrote:
>
>  H2 is not multi-threaded in this version. So a single long running 
> statement will block everything else. You'll either need to split it up 
> into smaller inserts (can still be a single transaction, just smaller 
> queries), or you could try turning on MULTI_THREADED=1.
>
> There is multi-threaded mode, but in this version it doesn't work with 
> MVCC. I think in the latest beta version it might work, but if you are 
> after reliability I'd go with breaking up your long running statement into 
> smaller statements.
>
> On 28/05/2014 1:45 AM, Brian Craft wrote:
>  
> Version 1.3.171. The only option I'm setting is MVCC, like 
> "somefile;MVCC=TRUE". I'll try to get a thread dump in a few minutes. 
>
>  Does this mean readers should not be blocked during the insert? 
>
> On Tuesday, May 27, 2014 4:18:01 AM UTC-7, Noel Grandin wrote: 
>>
>> Can you post a thread dump, so we can see where it is blocked? 
>> Also which version is this, and what does your DB URL look like? 
>>
>> On 2014-05-25 20:24, Brian Craft wrote: 
>> > I'm doing a large "insert into .. select * from CSVREAD ...", which is 
>> in a transaction. It seems to be blocking 
>> > readers, regardless of whether MVCC is enabled. Is this expected? If I 
>> understand the threads on MVCC, it will allow 
>>
>   -- 
> 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...@googlegroups.com .
> To post to this group, send email to h2-da...@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] Persistent console history

[Martin Grajcar]

Thank you for the fast answer. I guess I can do it, the only problem are
the Preferences limitation. There's no way to store WebSession.MAX_HISTORY
= 1000 entries as a single value as there's the Preferences.MAX_VALUE_LENGTH
= 8*1024 limit. Using multiple values gets complicated because of deletions
of duplicates. 1. It could be done trivially by always storing the whole
list, but this is ugly and could possibly take non-negligible amount of
time due to quickly filling FileSystemPreferences.changeLog). Or not; the
thing is rather complicated. 2. Doing some smart node reuse and re-linking
is rather complicated, but doable. 3. Limiting the stored history to 8 KB
would suffice for me.

So there are three possibilities, which one do you prefer?

Regards, Martin.


On Wed, May 28, 2014 at 4:36 PM, Noel Grandin  wrote:

> Sounds reasonable to me.
>
> The code you want lives in
> src\main\org\h2\server\web\WebApp.java
> src\main\org\h2\server\web\WebSession.java
>
> search for "@history" and follow the code.
>
> I suspect that the easiest option would be to have the console webapp
> store the history data using the java.util.prefs.Preferences stuff.
>
>
> On 2014-05-28 16:18, Martin Grajcar wrote:
>
>> The console history is a nice feature, but sometimes I get kicked out and
>> have to log in again and the history is gone.
>>
>> I don't know exactly when and why I get kicked out. Is there something I
>> could do about it?
>>
>> I didn't mean the persistency literarily, it's just that I'd love if it
>> could survive such events. Using cookies or
>> browser local storage or whatever... I guess I could do it myself, but
>> first I'd like to know your opinion. Does it make
>> sense? Where to start?
>>
>
> --
> 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] Unique index or primary key violation: "SYS_ID ON PUBLIC.SYS(ID)" [23505-168] (using 1.3.168)

[Nick99]

Same problem.

1.
The database was created in CREATE_BUILD 170, then was used with 1.3.174. 
I've tried using 1.4.178 on that database in Hibernate-based product - got 

org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: 
"PRIMARY KEY ON .PAGE_INDEX"; SQL statement:[...]

1.3.175 works ok on that db. 1.3.176 is not.

2.
Opening the db in 1.3.176 Console produces this (table names removed):

Unique index or primary key violation: "PRIMARY KEY ON .PAGE_INDEX"; 
SQL statement:
ALTER TABLE PUBLIC.-- ADD CONSTRAINT PUBLIC.FK28D9808AF98221CA 
FOREIGN KEY(JESID) REFERENCES PUBLIC.--(ID) NOCHECK [23505-176] 
23505/23505 (Help)


On Monday, May 26, 2014 10:33:05 AM UTC+3, Germano Rizzo wrote:
>
> Provided 
> here. 
> Thanks!
>
> Il giorno giovedì 22 maggio 2014 17:43:18 UTC+2, Thomas Mueller ha scritto:
>>
>> Hi
>>
>> I would need a reproducible test case, or the database file. 
>>
>> Regards, Thomas 
>>
>> On Thursday, May 22, 2014, jack jin  wrote:
>>
>>> when I upgrade to 1.3.176,I have the same problem.  the old version h2 
>>> is works fine with the db file
>>>
>>> On Tuesday, May 6, 2014 5:00:52 PM UTC+8, Germano Rizzo wrote:

 Hi Thomas,
 so your opinion is that all the db's are corrupted? The strange 
 thing is, they fail to open only with the latest stable version. Every 
 other version I tried works fine, and this configuration have worked in 40 
 installations for 3 years now, across different versions of H2. Do you 
 want 
 me to start another thread?

  Germano

 Il giorno martedì 6 maggio 2014 07:59:45 UTC+2, Thomas Mueller ha 
 scritto:
>
> 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  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.
>>>
>>

-- 
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] Persistent console history

[Noel Grandin]

Sounds reasonable to me.

The code you want lives in
src\main\org\h2\server\web\WebApp.java
src\main\org\h2\server\web\WebSession.java

search for "@history" and follow the code.

I suspect that the easiest option would be to have the console webapp store the history data using the 
java.util.prefs.Preferences stuff.


On 2014-05-28 16:18, Martin Grajcar wrote:

The console history is a nice feature, but sometimes I get kicked out and have 
to log in again and the history is gone.

I don't know exactly when and why I get kicked out. Is there something I could 
do about it?

I didn't mean the persistency literarily, it's just that I'd love if it could 
survive such events. Using cookies or
browser local storage or whatever... I guess I could do it myself, but first 
I'd like to know your opinion. Does it make
sense? Where to start?


--
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] Persistent console history

[Martin Grajcar]

The console history is a nice feature, but sometimes I get kicked out and
have to log in again and the history is gone.

I don't know exactly when and why I get kicked out. Is there something I
could do about it?

I didn't mean the persistency literarily, it's just that I'd love if it
could survive such events. Using cookies or browser local storage or
whatever... I guess I could do it myself, but first I'd like to know your
opinion. Does it make sense? Where to start?

Regads, Martin.

-- 
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] inserrting/updating CLOB using prepared statements

[Noel Grandin]

On 2014-05-27 17:24, Adam McMahon wrote:


I would like to use the Clob data type for my variable length strings that 
average around 300 characters.   I see in the
doc that I should use " |PreparedStatement.setCharacterStream| to store 
values".   Instead I am simply using
PreparedStatment.setString().   This seems to work.  Is there any advantage to 
using setCharacterStream?  This may be
more of a JDBC question than an H2 question, but I thought I would start in 
this group with the question.



At that size it makes no difference.

setCharacterStream() is there for the case where the CLOB is large enough that you don't want to keep the whole thing in 
memory at once.


--
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] Possible bug in LZF compression

[Thomas Mueller]

Hi,

Yes, it looks like this doesn't affect H2. Maybe it is related to the
changes to the LZF compressor in MapDB? My test case:

byte[] data =
StringUtils.convertHexToBytes("00ef76fa135e7d216e829a53845a983469ac1e4edb6120b79667d667e7d4f856010101010022bf4569010023002102123eeaa90e2f5786ce028e60ec03702706dadecee373a90b09b88a99cc668f46ac3358c8ea6433279c678846fb6e06eeccd82e2fe888f2ac203476d3918cd40579010038ff9e00be438253be4382530100109bf459010023002102123eeaa90e2f5786ce028e60ec03702706dadecee373a90b09b88a99cc668f46ac38bf80f10129594a7e949cc43c3bd6f8670ba5ab59874305f6839406738a9cf9010038ff9e0081bd175381bd1753");
CompressLZF lzf = new CompressLZF();
byte[] out = new byte[data.length];
int len = lzf.compress(data, data.length, out, 0);
byte[] test = new byte[data.length];
lzf.expand(out, 0, len, test, 0, data.length);
System.out.println(StringUtils.convertBytesToHex(test));
System.out.println(Arrays.hashCode(data));
System.out.println(Arrays.hashCode(test));

Regards,
Thomas


On Tue, May 27, 2014 at 1:57 PM, Noel Grandin  wrote:

> I massaged your test case into a unit test for H2, and it seems to be
> working for us.
>
> But maybe there is some more transformation that happens to the raw byte
> array before it hits the LZF compressor.
>
>
> On 2014-05-27 13:46, Jan Kotek wrote:
>
>>
>> MapDB uses LZF compression from H2 database. One of our users reported
>> wrongly decompressed 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.
>

-- 
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] insert sorted/direct

[Thomas Mueller]

Hi,

Without the DIRECT option, the query is first executed completely (rows are
read in memory, and possibly buffered to disk if there are many rows), and
only after that they are inserted into the table. With the DIRECT option,
rows are inserted into the table while executing the query.

Once "server side" cursors are implemented, this distinction is no longer
needed (rows are never buffered when using server side cursors).

Until then, you can try using the DIRECT option if the default setting are
too slow for your.

Regards,
Thomas



On Tue, May 27, 2014 at 1:24 PM, Noel Grandin  wrote:

>
>
> On 2014-05-27 02:35, Brian Craft wrote:
>
>>
>> When using |SORTED|, b-tree pages are split at the insertion point. This
>> can improve performance and reduce disk usage.
>>
>
> I don't know what the DIRECT option is up to, but the SORTED option allows
> the insertion process to be more efficient because it can assume that the
> incoming data is already correctly sorted for the target table.
>
>
> --
> 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] probably non-optimal referenced entity handling on row delere

[Noel Grandin]

On 2014-05-27 20:51, san...@zeroturnaround.com wrote:

So what do you think.. something that could be improved here? H2 seems to spend 
most of its time in places like
TreeCurson.next()  and other index-related methods. Just a wild guess: maybe it 
is recalculating some index a million
times (after every updated row update), instead of first doing all the updates 
and then recalculating the index just once..?



No, it's spending all of it's time deleting rows and checking that the deleted rows are not used by a referential 
constraint.


I would suggest figuring out which query is the problem child, and then doing 
an EXPLAIN PLAN on that query.
You're probably missing an index somewhere and it's doing lots of table scans.

--
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.