Jared Chapman

However, it doesn't necessarily have to be the GUI. It could be a layer on the server side that sits on top of Data.

Exactly. All my filterings is done on the server side.

-Max's Book
-Head First Design Patterns
-THIS FORUM!!!

Ditto what Matt said. That's how I handled it. But be SURE to document exactly why you did it that way, and other ways you considered.

Hey David,

I played with the idea of doing something with these values, too. After all, in the real world these values should be separated, so a search could be performed on a particular specialty. But it is beyond the scope of the assignment. Just leave these values in a single string.

I declared 2 private variables:

private final int VALID_FLAG = 00;
private final int INVALID_FLAG = 0x8000;

Then, when I'm reading a record, I do the following check:

int flag = db.readUnsignedShort(); if(flag == VALID_FLAG){ //code to deal with valid record } etc...

Hey Alan,

The first think you should do in the read method is to check the flag. So to do this, you should navigate to (offset * recNo) in your data file. Then, you read the flag. If the record is marked as valid, then return the fields (i.e. name, location...etc) in a String[]. If the record is marked as invalid, then throw a RecordNotFoundException. At this point, the file pointer will be at the beginning of the first field (name). If the record is valid, read the fields of the record, populate your string array, and return it.

As far as deleting a record goes, you simply want to navigate to (offset * recNo), which will put you at the flag, and write OxFF. So according to my specs, you don't use read or update at all to delete a record, but rather use a delete(recNo) method.

Hope this helped.

I wouldn't return this with the String[]. If the flag specifies that the record is deleted/invalid, then just throw a RecordNotFoundException.

Make your life easier - when the user starts the program in local mode, they can either connect to a database, or press cancel. If they press cancel, just simply exit the application altogether.

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.

I just made sure there was some input, and that the input was made up entirely of numbers, and that there were no more than 8 of them. In the case where there are less than 8 digits entered, i add the appropriate number of leading 0's.

Hi Mihai,

I have to go to work right now, but I will reply on my locking mechanism
when I get home tonight.

I didn't start my documentation until I was done coding (except for the javadoc documentation), and by that time i was ready to turn this %#*$# thing in. So I guess I didn't spend as much time as I should've on it.

On deck: SCWCD, then IBM's XML cert.
[ April 14, 2005: Message edited by: Jared Chapman ]

Thank you all here at the ranch for your help. I couldn't have done it without you. Here's a breakdown of my score:

Gen Considerations : 90/100
Documentation : 62/70
Obj Oriented Design: 30/30
GUI : 34/40
Locking : 80/80
Data Store : 40/40
Network Server : 30/40

Total :366/400

Good job Daniel! So what's next?

I read over my design choices on the drive over to Prometric.

I hope you weren't the one driving...