URLyBird 1.1.1

[Eva Van Shtock]

Hello,

I just started doing this assignment and I was wondering if someone can help me.

In the DB interface:

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


The database, as defined by Sun, does not have Primary key. Furthermore, no combination of the fields can be used as a primary key.
It is perfectly legal, as I can see, to have two rooms with same field values.

Now, for this create method implementation, what should I do. I can perfectly ignore this DuplicateKeyException. Is it wise?
Can I throw it in the case of IOException? I think I should since I cannot define new Exceptions.


What you all think?


Please help.

Eva

[B Chen]

Your create() method don't need to throw DuplicateKeyException if the implementation doesn't have a need to do so. You can even leave the throws specification out.
Using DuplicateKeyException for any other reason (to handle IO exceptions) would not be a good idea.

[Eva Van Shtock]

Chen,

That would be a good advice. Howver, what can you return to the user?
The interface method is given as:

// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create (String[] data) throws DuplicateKeyException;


As I said before, nothing in the database (single or combined) can be used as a primary key.
What should I return to the user? If I return -1, it is still an integer and he will use it as record number!

I see no other choice but to use the DuplicateKeyException as an indication for failure.

I'm open for any suggestions.

Eva

[B Chen]

The primary key can be anything that uniquely identifies a record. It does not have to be in the data itself. So what do you think can serve as the primary key in this application?

[Eva Van Shtock]

Chen.
I can use anything for the primary key. I could easily use sequence number.
The question is how can duplicate key error occur? The client give me a record to add and you never get duplicate record! As I said before, there can be identical rooms in the DB and it is OK.

So, is it a design decision to use this exception for DB access error etc.?

Regards
Eva

[B Chen]

Yes, it would be a design decision. But most developers would agree it is a bad design decision. There are better ways to handle access errors.

[Andrew Monkhouse]

Hi Eva,

The question is how can duplicate key error occur? The client give me a record to add and you never get duplicate record! As I said before, there can be identical rooms in the DB and it is OK.

Sun have stated in the past that some parts of the assignment deliberately emulate users who are asking for things that contra-indicate either other parts of the assignment or even just what we would expect. In real life, we would be expected to go back to the customer and talk through the problems with them. Sun want to see that as developers we can spot the issues, think of solutions, and then describe the solution we decided to go with in our design decisions document.

So, yes, it is possible that you could have two identical rooms, which makes the DuplicateRecordException redundant.

So, is it a design decision to use this exception for DB access error etc.?

As B Chen says, this is a design decision, but it might not be the best design decision.

Think about it from the perspective of a junior programmer who has just joined the company and has to work with your Data class. They start looking at the create() method, and notice that it can throw a DuplicateRecordException. Why would they expect that to mean anything other than the fact that there is a duplicate record? Telling them that a DuplicateRecordException might be thrown if there is a duplicate record, or if there was a permissions problem, or if there was an IO problem, or if there was a .... is just going to confuse them.

Wouldnt it be better if the Create method threw DuplicateRecordException and DBAccessError? (Hint, take a look at what java.lang.RuntimeException can offer you.

Regards, Andrew

[Jeroen T Wenting]

Also consider that while the supplied record format does not contain a unique key (and thus will never have a duplicate key) the DB format is a generic one that can be applied to other record definitions that DO have a key.

That's one reason why I created my entire database structure as a generic system, with subclasses where needed for the specific implementation required for the assignment.
That way if a table were to be added only 3 classes would have to be created on the serverside to support it (a class for the file operations, one for the metadata, and a class to serve it over RMI).
I'm still somewhat uncertain about it though, I feel it can be made more generic still at the cost of slightly higher complexity and am not sure whether to do so or not.