[
https://issues.apache.org/jira/browse/DERBY-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735320#action_12735320
]
Kathey Marsden commented on DERBY-4166:
---------------------------------------
Lily said in an email
> Yes, it is schemachange2. I need the same Id in attach table because it is a
> foreign key of inbox. I don't know how getGeneratedKeys work. Does it get the
> same key in inbox?
Yes. getGeneratedKeys() will get the id that was just inserted into the inbox
identity column, so you don't have to query the table to get it. See
http://java.sun.com/javase/6/docs/api/java/sql/Statement.html#getGeneratedKeys()
and
http://db.apache.org/derby/docs/dev/ref/crefjavstateautogen.html
for information
and the test AugoGenJDBC30Test for examples.
Lily also said:
>Since delete thread will delete data in inbox table, the id in inbox table
>will keep changing as test run.
I have not studied the delete logic carefully, but will take a look. It should
be able to accommodate the approach I described for the inserts without
deadlocks.
Because we will be inserting each email content and attachments as a single
transaction, the delete thread should not consider it for deletion until the
insert is complete and the id we get with getGeneratedKeys() should still be
valid when we insert the attachments.
> improvements to the mailjdbc test
> ---------------------------------
>
> Key: DERBY-4166
> URL: https://issues.apache.org/jira/browse/DERBY-4166
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.6.0.0
> Reporter: Kathey Marsden
> Priority: Minor
> Attachments: DERBY-4166-databasesize.diff, Derby-4166-samedb.diff,
> DERBY-4166-schemachange.diff, DERBY-4166-schemachange2.diff, Derby-4166.diff
>
>
> When recently working with the mailjdbc system test
> org.apache.derbyTesting.system.mailjdbc on DERBY-4152 I noticed some
> potential improvements that might be good for the test. We should probably
> hold off on these improvements however until the root cause of DERBY-4152 is
> established, however, so we don't muddy the waters with that issue by
> changing the test.
> 1) DbTasks.moveToFolders may throw an IllegalArgumentException.
> There is a line: message_id = Rn.nextInt(count - 1);
> if count is 1 the argument to nextInt() might be 0 which is not allowed. I
> hit this once but lost the stack trace, but it is apparent that when there is
> only one row in the table this can occur.
>
> 2) Allow/implement multiple attachments per message and cleanup
> DbTasks.insertMail() logic.
> - Remove the attach_id column from INBOX to allow multiple attachments.
> -Make the attachment insert part of the message for loop in insertMail.
> Use getGeneratedKeys() to get the id of the inserted message.
> When attachments are inserted, insert (1-4) attachments and give them a
> corresponding attach_id from 1-4.
> This will allow for removal of the select statements used to determine id and
> attach_id. I'll file another issue for these improvements if folks agree
> that they are sensible.
> A detailed description of the current implementation of insertMail is
> described at
> https://issues.apache.org/jira/secure/attachment/12405685/insertMailSummary.txt
> 3) DbTasks.databaseSize calculation is wrong. It doesn't match du -sk. The
> method does not recurse into subdirectories and includes the length() on
> directory files which is undefined accourding to the file.length() javadoc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
