I've chosen to use the record number as the key, but assuming a correct program, this negates the possibility of throwing a DuplicateKeyException.
I'm aware that I could also insist that the contractor name (for example) must be unique, but I don't really see the point - apart from the fact that this would "enable" me to throw a DuplicateKeyException.
I'm concerned that I might be automatically failed if my Data class never actually throw this exception even though the DBAccess interface says it might. I don't think I should be though, because a class C which implements an interface I, but doesn't throw all of the exceptions listed in I, is still a correct implementation of I. I'd be interested to hear whether others think this might result in automatic failure, or loss of marks?
This is an often discussed topic in this forum. There are many opinions on what to do with the DuplicateKeyException. You'll probably find some of the discussions using a search on "DuplicateKeyException".
I choose not to throw it (using the same reasoning as yours) and I got full points on my server part.
The most interesting point about this topic is IMHO the question why the update method does not throw a DuplicateKeyException in the interface...
I feel that it is not a good idea to use existing fields (whether single or composite) to act as a primary key. Record number is the way to go. Why?
From the way they presented the database format, it seems that they expect the Data class to be reusable. The main evidence lies in the fact that the update method does not throw DuplicateKeyException. If we simply assume, for instance, that the first 2 fields will act as a composite key, then this is bad assumption, as this may be true for our assignment databases, but not for other databases. However, using record number is ok, since every record number is guaranteed to be unique.
I think I will do the same thing as Frans. Simply not throw the exception, and remember to document it. [ April 23, 2005: Message edited by: Liang Anmian ]
I chose to implement a primary key in my assignment, and I chose the name+location composite key to be the PK.
If we simply assume, for instance, that the first 2 fields will act as a composite key, then this is bad assumption, as this may be true for our assignment databases, but not for other databases. However, using record number is ok, since every record number is guaranteed to be unique.
Don't you read in the magic cookie value and verify it before doing anything with the data? The magic cookie identifies the file as a valid data file with the required columns (it is tied to assignment + version number), so you are fine assuming that the PK will work.
This is the first I heard of someone using the record number as the primary key... I am assuming it would work (because all it has to do is uniquely identify the record)... Let us know how it turns out for you. Good luck.
What? I actually thought that Sun put the magic cookie value there just for the sake of putting it there! When I parse the file in the constructor of Data, I simply discard it! You mean there is a significant use of that value? My assignment only says:
4 byte numeric, magic cookie value. Identifies this as a data file
From this description, I merely assume that it simply identifies the file as a database file with the same database format, but may not contain the same fields and records.
After reading your reply, I searched the forum for similar posts. According to them, they used the magic cookie value to verify that the filename being supplied to the constructor is a valid database file. But, how do you know in advance what is the magic cookie that you are expecting? I got a feeling that they parse the database file first, prints the magic cookie value on the screen, then they hard code that value as a constant in the Data class.
Oh boy looks like I'm really missing something major! [ April 24, 2005: Message edited by: Liang Anmian ]
Originally posted by Liang Anmian: Oh boy looks like I'm really missing something major!
If it is of any comfort: I don't think you are. Although Paul has a valid point that the magic cookie value seems to be related to the assignment version, it is nowhere explicitly stated that the cookie identifies the file as containing a specific sort of data.
I think that in a "traditional server-client" system, the database layer should not define what the primary key for a record is; this is defined by the business tier. And if it had to be defined in the data file, I would expect it in the field definition section of the file.
I've read in this forum a post by someone who added a method to the data tier which the business tier could call to tell what the PK fields must be. It sounds a bit complex to me, but I think that is a valid implementation for people who chose to have a proper PK.
I choose the way of least resistance and decided to go with the "record number is key" flow, which seems to be very acceptable with the assessors.
I never throw a DuplicateKeyException in my solution. Here are the possible solutions I considered while deciding what to do with this problem:
1. use the record number. This is not a good primary key for the required specs. When we create a new record, we are to find a deleted record and use it's record number, or append the new record to the end of the database. So you never actually manually specify a record number for a new record (your implementation of create finds one for you and returns that value), and therefore if your implementation of create works correctly you will never have a DKEx.
2. Use a combination of name and location. I also decided that this wasn't a good choice. If you hardcode a primary key into your Data class, then the class loses some of its reusability. If you want to use this Data class on a different set of data, then you may have to go in and modify the Data class to adjust the primary key for this new set of data. ALSO, I didn't feel it was safe to assume that name and location will always be unique with the supplied specs. What if two branches of a particular contractor are added to the database, and they both reside in Chicago? Given the size of Chicago, it is reasonable to assume that this could happen.
MY SOLUTION: I put a comment in the beginning of my create method, explaining that this is where I would do a check and throw a DuplicateKeyException, if in fact there was a valid primary key to check. I also explained in this comment why I didn't decide to throw one (in addition to the above comments, I also explained that I thought the primary key field(s) should be specified in the schema of the data file). I also explained this in my choices.txt. And I got 40/40 on my Data Store.
Thanks everyone. I got to this point in the assignment and had already decided to use record number as the PK. This thread helped to clarify some of the issues surrounding this approach.
It may be that the DuplicateKeyException is included in the interface for those who choose a differnt implementation. As everyone has noted, we dont have to throw the DuplicateKeyException, but for someone who is using a composite index, they may NEED this type of exception, therefore it is included in the DBAccess interface.
My .02.
Chris [ May 02, 2005: Message edited by: Chris Mahood ]
Post by:autobot
Hot dog! An advertiser loves us THIS much:
a bit of art, as a gift, that will fit in a stocking
![[Logo]](/templates/default/mobile/images/mobile-moose.gif)
