Thanks, Mike. Answers inlined.
On 04. nov. 2013 19:54, mike matrigali wrote:
I think you must be right, and likely we should document it.
For performance during import with replace the system does not
log each insert, instead it "knows" that it can abort by just
putting an empty table. If you don't commit after this then
I think you start getting a mix of log records in the abort
stream.
Yes, that makes sense.
At least in 10.7 doc we note that derby does this commit, but the
section seems to have disappeared in later releases:
http://db.apache.org/derby/docs/10.7/tools/ctoolsimport27052.html
It has moved to the admin guide:
http://db.apache.org/derby/docs/10.10/adminguide/cadminimport27052.html
In addition this this material, the individual import/export procedures
in the reference manual should carry this important information, I think.
Dag
it says:
Database transactions
You should issue either a COMMIT or ROLLBACK statement to complete
all transactions and release all table-level locks before you invoke
an import or export procedure. Derby issues a COMMIT or a ROLLBACK
statement after each import and export procedure is run.
Note: Imports are transactional. If an error occurs during bulk
import, all changes are rolled back.
On 11/4/2013 8:37 AM, Dag H. Wanvik wrote:
Hi,
I read our reference manual for import table, but it doesn't mention
this. Can anyone explain why we
do an implicit commit? I thought the import statement was transactional;
I can imagine
it's because with replace option we truncate the old table would roll
back not via the log but by undoing the creation of a replacement
conglomerate.
In any case, the reference manual should mention this prominently, I
think.
Code reference: line 1580
http://svn.apache.org/viewvc/db/derby/code/branches/10.10/java/engine/org/apache/derby/catalog/SystemProcedures.java?view=markup
I'll file a doc issue if this is as it should be.
Thanks,
Dag
