NX:Duplicate Key when updating

[Tony Collins]

Assuming we assume that there is the possibility of a duplicate key exception when creating a entry in the DB, shouldn't there then also be a duplicate key exception when updating the DB. Though update can only throw RecordNotFound and Security Exceptions ???
Or should we not allow the primary key to be updated in an update, but this doesn't seem to hold with the API.
Tony

[Mark Spritzler]

Actually this has been discussed many times in this forum, and you can do a search on the duplicate exception to find them.
Here is my take, everyone has correct ideas for there needing to be a Duplicate key exception being thrown in update by the nature of the new assignments. However, this is correct in the real world. But you would also in the real world make an update method not allowed to change the Primary Key, so therefore in the real world you would not need the duplicate key exception because of the constraints.
Now in the assignment, adding the duplicate key exception will change the signature of the Sun provided interface, which could cause problems and points lost. I would suggest not updating the primary key when you call the update method, and then you do not have to worry about Duplicate Keys, and you can remark on this in your design.txt/choices.txt document.
Mark

[Philippe Maquet]

Here is my take, everyone has correct ideas for there needing to be a Duplicate key exception being thrown in update by the nature of the new assignments. However, this is correct in the real world. But you would also in the real world make an update method not allowed to change the Primary Key, so therefore in the real world you would not need the duplicate key exception because of the constraints.

Sorry Mark, but even in the real world, you cannot do both ("a Duplicate key exception being thrown in update" and "an update method not allowed to change the Primary Key").
And reading my own instructions, I am not sure it's an issue we should just solve by a remark in our design.txt/choices.txt document :

This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.

A possible choice is to throw some exception extending "java.lang.IllegalArgumentException", given Sun's definition of the latter :

Thrown to indicate that a method has been passed an illegal or inappropriate argument.

Best,
Phil.

[Mark Spritzler]

I think everyone is missing the point of the assignment, and are making it more difficult than it needs to be. The most important parts of the assignment are ease of reading, a junior programmer can maintain it, and following directions. Overly complicating things makes things tougher for the grader to grade the assignment, and therefore make them want to grade the assignment a lower score.
Since it was designed to not have this excepetion thrown, it was meant to be that way. The designers of the assignment are very smart, they wouldn't put a problem like this in the assignment and not analyze it or change it if it was wrong to them.
I make my statements based on two years of moderating this forum. I have seen many programmers overly complicate things and get lower scores than they had hoped, and in each case, they state afterwards that they understood that this was their downfall, and highly recommend keeping things as simple as possible.
This assignment is not rocket science, and not too difficult. So why make it difficult by over analyzing everything. The update method does not need a DuplicateKeyException thrown. The assignment specifically has you only book the record which means the field you want to update is not part of the primary key.
I am sorry if this sounds short, it is not meant to be. I am really only trying to help and keep people from pulling their hair out when they don't need to be.
Mark

[Philippe Maquet]

Hi Mark,

I am sorry if this sounds short, it is not meant to be.

It was not so short ...

The designers of the assignment are very smart, they wouldn't put a problem like this in the assignment and not analyze it or change it if it was wrong to them.

Sorry, but this is part of the instructions :

This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.

The most important parts of the assignment are ease of reading, a junior programmer can maintain it, and following directions.

Any junior programmer I've had the chance to work with would point out the design flaw there is in the DBAccess part of the instructions comparing createRecord() and updateRecord() method signatures.
Now that that flaw is recognized, it's up to us (I mean each one of us) to decide what to do with it :

simply ignore

simply mention in choices.txt

simply implement a reasonable solution to the issue

Well, in this case, I chose option 3.

The assignment specifically has you only book the record which means the field you want to update is not part of the primary key.

You are talking about the "business" part of the assignment. Beside it, we must implement DBAccess interface in class Data, even for methods we'll not use (createRecord() and deleteRecord()). So I don't think that just telling that we won't get the opportunity - in our business tier - to crash a given primary key in updateRecord() is a good justification to ignore the Data.updateRecord() flaw.
Best,
Phil.

[Jim Yingst]

[Mark S]: The designers of the assignment are very smart, they wouldn't put a problem like this in the assignment and not analyze it or change it if it was wrong to them.
The designers are smart, but many customers in the real world are not so smart, giving incorrect, misleading, and/or contradictory statements in their requirements, or leaving out information that really should be there (like an explanation of DuplicateKeyException if it's really so damn important). I believe Sun is intentionally simulating customers who are not as smart as the assignment creators themselves.
Most of my other thoughts on this issue can be found here; no need to repeat them now. Cheers...

[Tony Collins]

I think it is just a case of profesional pride and wanting to do the job as good as you can. I think of it as first a learning experience and then a cert.

Tony

[Mark Spritzler]

I believe Sun is intentionally simulating customers who are not as smart as the assignment creators themselves.

I understand, however, in the case of the Update method, this is not the case. You are updating either the customer field, or available seats, or available rooms field. You are not asked to update the primary key fields.
Anyone can think what they want and make decisions on what they think. I will not stand in anyone's way in added the exception to the throws clause. I just strongly believe that you will be docked points because of it, based on my experience.
Mark

[Jim Yingst]

I think it is just a case of profesional pride and wanting to do the job as good as you can. I think of it as first a learning experience and then a cert.
I agree. But simplicity is a virtue too, so "doing the best job I can" is not necessarily incompatible with "keep it simple".

[Jim Yingst]

Anyone can think what they want and make decisions on what they think. I will not stand in anyone's way in added the exception to the throws clause. I just strongly believe that you will be docked points because of it, based on my experience.
To clarify, I personally don't advocate adding the exception to the throws clause either. I'm advocating not throwing DuplicateKeyException at all, but leaving it declared in the original interface because of course we can't change that.
If I were to put in code in create() that could actually throw a DuplicateKeyException, I would also strongly favor throwing an IllegalArgumentException from update() in case a junior programmer tries to use it to change a key. This doesn't require any throws clause, as IllegalArgumentException is a RuntimeException.

[Bharat Ruparel]

Er! I am a bit embarassed to ask this question. As far as the URLyBird assignment is concerned, what is the primary key? Before I get to duplicate key exception, I need to know how and when this exception will be created?
Thanks.
Bharat

[Philippe Maquet]

Hy Bharat,
There is no possible primary key used in the URLyBird data file, but - reading the createRecord() signature - Data should be able to handle one (IMO). This has been discussed in detail recently. You may try a search on "DuplicateKeyException" for more details.
Best,
Phil.