Problem is related to createRecord and updateRecord, both of which should handle duplicate key if any. However, only createRecord throws dupex. How do I do with updateRecord? Some thread mentioned to ignore this case at all. Is this appropriate?
For example, if we defined the dup case as:
1. all input fields are null, or,
2. name and city fields are null
How should I handle it update? There are some conceived solutions:
1. extends dupex from runtime: not good (db shouldn't die if there are duplicates)
2. ignore dupex: not good (db should handle the above case)
3. for update, relying on upper level calling function to do input validation. (feel like put a patch to a new Shirt).
DuplicateKeyException is thrown in the create method if the record number found to be reusable (or an entirely brand-new one) somehow contains a valid, non-deleted record just before writing the data out. To be justifiable, these steps must be together atomic.
David: in your suggestion, how do you let the calling function know if the update was done or failed?
Anton: I didn't understand your method
DuplicateKeyException is thrown in the create method if the record number found to be reusable (or an entirely brand-new one) somehow contains a valid, non-deleted record just before writing the data out.
How does this dup case will be raised? all modifiable methods are to be synch on an object, in which it can't have a case for create to reuse on an undeleted record (in my implementation). Furthermore, as I understand the input data doesn't contain recNo. recNo is generated internally.
Mmm, this makes sense:
I throw a SecurityException if I try to update a record which is different from the data passed in. It is a security issue: data will be logically corrupt if this update happens.
The dup case I described above in update may result in database corruption so wrap it into secex sounds reasonable. Doesn't it?