Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DuplicateKeyException B&S

 
Liviu Carausu
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I do not know if I should really throw DuplicateKeyException from the create() Method. I have B&S application. I think that I can make a primary key
created from Name And Location (two Subcontractors with the same name in town does not really make sense, or ?).
Another problem that I have is that the update() method does not throw the DuplicateKeyException.
What do you think ?
Thanks,
Liviu
 
Romeo Son
Ranch Hand
Posts: 92
Android Eclipse IDE Suse
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I also have B&S and I have decided to not throw DuplicateKeyException even if it's declared in the interface because the specification it's unclear about a primary key, I know others that adopted this approach and they were fine, I will argue my decision in choices.txt.
 
Mark Ebeling
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,
I am throwing the DuplicateKey exception on the createRecord method. But I am declaring in my choices.txt that I assume Name and Location are keys to the contractor database. I felt that contractors may have many different locations, but the other fields don't really apply to make them unique.

Cheers.
 
Liviu Carausu
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Ebeling:
Hey,
I am throwing the DuplicateKey exception on the createRecord method. But I am declaring in my choices.txt that I assume Name and Location are keys to the contractor database. I felt that contractors may have many different locations, but the other fields don't really apply to make them unique.

Cheers.


Hey,
Thanks for your answer... Still, what do you think it should happen if the update method creates a record identical with a existing one ? Should a RuntimeException than be thrown ? In my opininion the interface needs the DuplicateKeyException for the update method .
Help !
Thanks !
 
Liviu Carausu
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Romeo Son:
Hi,

I also have B&S and I have decided to not throw DuplicateKeyException even if it's declared in the interface because the specification it's unclear about a primary key, I know others that adopted this approach and they were fine, I will argue my decision in choices.txt.


Hi,
Thanks for your answer. It is a point of view and it can spare some headaches.
Regards,
Liviu
 
Mark Ebeling
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hey,
Thanks for your answer... Still, what do you think it should happen if the update method creates a record identical with a existing one ? Should a RuntimeException than be thrown ? In my opininion the interface needs the DuplicateKeyException for the update method .
Help !
Thanks !


I see your point. I had not thought about updates to the key fields which definitely could happen, possibly creating duplicate keyed records. I think it makes sense to not update the keys, but only if they create a duplicate key. In that case, I would have to wrap the DuplicateKeyExcption in a RecordNotFoundException or the SecurityException. I don't really like either option.

So I may decide to not throw DuplicateKeyException. Still unsure.
 
S J Martin
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought about this for some time. Eventually I decided that the RecNo was a more appropriate PK (given the rest of the interface) and thus have chosen to ignore the DuplicateKeyException (beyond choices.txt ;-) . I remeber seeing a message here from someone who passed with a good score who had taken this approach. I'm sure it is one of the "red herrings" that they've thrown into the spec to see what you make of it.

I doubt you'll gain / lose points either way as long as:
  • a. You are clear about your approach.
  • b. You approach is a sound workable solution.

  •  
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic