Hello, I recently had many troubles with my database incremening in size (10x size with MV_STORE). I found I could SCRIPT TO bak.gz and RUNSCRIPT bak.gz to an empty database to rebuild it and bring it back to actual size.
Well it was good and all, after I found a bug 1 second before putting the whole thing in production. The bug is as follows: My columns with data type 'TIMESTAMP AS NOW()' when restored from a SCRIPTED db get modified with current timestamp, invalidating millions of rows. I find the system used by H2 to be very intrusive because a) I cant update timestamp by myself in no way (update MY_TS just replaces again MY_TS with NOW() regardless of what timestamp I choose) b) makes trouble with restore, replace and probably other cases I have checked other database systems and I read they use 'ON UPDATE' or custom triggers that just activates when actually the user is updating the row, this is a totally more SANE way to update the value that does not modify the db with incorrect valeus on restore. The problem with H2's approach is that it does not differentiate human control between routine/machine control. At least I think it should BY NO MEANS update 'AS X()' columns when restoring with RUNSCRIPT. at least this would allow a restore to take place How can I solve this? I absolutely can't stand MV_STORE because the database is going to become huge and it impacts 1) backup times 2) usability 3) space 4) memory Thank you for your time in advance -- 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 https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
