• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Inconsistency in DBAccess interface

 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Andy Zhu
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
reply
    Bookmark Topic Watch Topic
  • New Topic