Hmmm, we need to investigate the Ajax check. There was no change in
addPerson (the form), only in addPersonResult. Also additional id field
in the PERSON table should not have broken the addPerson. But obviously
it did. This needs some more investigation.
As for the undoing of the two transactions, it would not be reasonable
to undo the whole transaction because the image copy alone failed. Even
if you don't upload any image, the transaction would be a pass. I count
the image update as a peripheral functionality to the main transaction.
Given that, I don't think a full rollback is necessary. A real app would
allow you to upload images later, too.
So it's back down to the Ajax check.
-Akara
Shanti Subramanyam - PAE wrote:
I just ran into this issue :
I registered a new user manually. Due to a bug in some code I was
testing, the image did not get created.
So I fixed the code and re-tried - using the same username again.
Guess what ?
a) Firstly, the AJAX check that used to be there where it would tell us
'Valid username' or not seems to have disappeared.
b) The operation failed with Duplicate Key exception, claiming that the
user already exists. This even though, the previous operation had
clearly failed.
I know Akara fixed up the transactions such that we first add the
database row, then add the uploaded files and finally go back and modify
the database to fix the URLs for the images. All of this is obviously
not being done within one database transaction.
If we do want to use multiple transactions for performance reasons, then
don't we need to ensure that any failure after anything is added to the
database undoes that change ?
Shanti
