aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Inconsistency in DBAccess interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Inconsistency in DBAccess interface" Watch "Inconsistency in DBAccess interface" New topic
Author

Inconsistency in DBAccess interface

Andy Zhu
Ranch Hand

Joined: May 26, 2004
Posts: 145
I mentioned problem in other thread but think the problem is worth its own discussion.

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).

What else?

Thanks


--------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
David Dong
Ranch Hand

Joined: Aug 15, 2004
Posts: 58
Here is an idea that just came to my brain.
If the update record is duplicate key, you don't update the record. If the update record isn't duplicate key to the database, then you update the record.
I hope it help.
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
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.

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.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Andy Zhu
Ranch Hand

Joined: May 26, 2004
Posts: 145
Thanks for your reply.

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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Inconsistency in DBAccess interface