File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Soft Skills: The software developer's life manual this week in the Jobs Discussion forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird 1.1.3, data validation and Primary Key, are my assumptions correct?

 
Eric Chou
Greenhorn
Posts: 20
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, everyone,

I am struggling with the DB interaction methods. I found I have to have several assumptions before I write the code.

At first, database record does not have primary key specified (at least not specified in the instructions). Can I assume that the combination of Hotel Name and Hotel Location can uniquely identify a record? In anther word, those two fields could be the primary key of the records. Since the instructions does not say which field(s) I can use as primary key, and the physical position index of the record is not sufficient to be used as a primary key, can I just make the assumption above and specified this assumption in the choice.txt?

Second, data.java is the only interface that application operates underlying database file. This interface has method "create" and "update", which theoretically can assign any kind of values into the fields. I believe the assessors have applications which can automatically try this two methods with different parameters. Can I assume that the parameters are all following the value rule of each field? For example, the "smoking" field should only accept "Y" or "N", anything else is illegal. Do I have to validate the values when they are coming in? Or just make an assumption and leave this issue to the caller side?
 
Ernesto Elias-Nieland
Ranch Hand
Posts: 53
Eclipse IDE Spring Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eric,
I think you can just use the order of the records in the database file as the primary key.
Name and location of the hotel is not sufficient, since a hotel can have many similar rooms, which would violate your primary key. At least in my assignment, the combination of all fields of a record is still not unique enough for a primary key.
This is why a simple number (like the order in the file) is the only way to distinguish the records uniquely.

Cheers,
Ernie
 
Jeffry Kristianto Yanuar
Ranch Hand
Posts: 759
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eric,

I used the record number for the primary key, the record number is based on the appearance of the record, so the first record get no 1, second record get no 2, and so on. hope this helps.

Jeffry Kristianto Yanuar
Java Instructor
SCJP 5.0
SCJA
SCJD (Working on UrlyBird 1.3.2) --> testing and documenting the assignment
 
Eric Chou
Greenhorn
Posts: 20
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Ernesto and Jeffry

I understand the record index number could be the best choice of primary key in most situations. However, there is an exception : possibly reusing a deleted record when a user creates a new record.

The method create() is defined as following:

public int create(String[] data) throws DuplicateKeyException;

How can you know when will you reuse a deleted record? I believe you have to compare something. Unfortunately, the parameter "data" does not have a room for record index number, it only contains the field such as "hotel name","hotel location", etc. Therefore, I have to find a primary key within the fields so that I can tell whether I should reuse a deleted record or not. And, if I can use a primary key which consists with the data of fields, the DuplicateKeyException makes more sense.

What do you think about this issue, my fellow ranchers ?

Thanks again for any replies

Eric
 
Ernesto Elias-Nieland
Ranch Hand
Posts: 53
Eclipse IDE Spring Tomcat Server
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eric,

Actually, I just don't reuse any deleted records. My requirements don't say MUST, so I don't do it, which makes life easier.
However, if a record is deleted you can just set the deleted flag and don't have to actually delete the data from the file. By this, all indexes are still valid after a delete. During the initial read of the db file I just skip all records that are "deleted" and increment the primary key.

Cheers,
Ernie
 
Jevgeni Zhukov
Greenhorn
Posts: 18
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I used the location in the data file as recNo/record ID.
While creating a new record I was iterating over records finding the first deleted one. I never threw DuplicateKeyException.

As to validation, I only checked every fields' length and complience to 8 bit US ASCII.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic