URLyBird Primary Key

[Shan Jun Hao]

Hi,

Just started on my SCJD and this is my first post here.

I realise that the data provided by SUN does not contain a primary key. The interface which I am required to implement - DB.java has this int recNo that will be used for CRUD operations. I also have the Hotel.java which I am going to use as a value/transfer object.

My question is I am thinking of including the field recNo as a key identifer in my Hotel.java, any comments? And also, any suggestion on how should I implement this recNo?

[Shan Jun Hao]

Alright, after much thorough thinking, I realised my questions are stupid. I have found out the way to do it. Sorry for this post.

[Miles Toliver]

Hi Jeffrey,

I don't think your question was stupid, and I had asked myself a similar question as Sun does not provided a place in the database file in which to persist this primary key recordNum that the interface uses. Therefore, I was thinking that the only way to implement the recordNum would be to using the starting position in the file for each record as that record's recordNum. This should work but there are are some concurrency pitfalls I can think of with this solution (but they are probably out of scope for the SCJD project).

I am curious if you reached the same conclusion or if you came up with some alternative.

Thanks,
Miles

[Tom Nicki]

Hi Miles,

I have the same solution. I thought rather about using record order number than offset but this make no difference.

What about "possibly reusing a deleted entry" and "DuplicateKeyException" in

// 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 long createRecord(String [] data)
throws DuplicateKeyException;

Do you have it in your assignment? What solution do you have for it?

Tom

[Mihai Radulescu]

Hi people


I think that SUN does this with puropose - I mean to omit the primary key.
IMHO the primary key depends on your Data layer logic.
You can calculate/generate one using the record information and your Data logic.
By example (I have the URLyBird) on my case it make sense that a record apears two times in the database - because a hotel can have more than one room with the same attributes, so I chose not to throw any DuplicateKeyException.

What you guys think about ?



regards M
[ June 28, 2006: Message edited by: Mihai Radulescu ]

[Tom Nicki]

I think that SUN does this with puropose - I mean to omit the primary key.
IMHO the primary key depends on your Data layer logic.
You can calculate/generate one using the record information and your Data logic.
By example (I have the URLyBird) on my case it make sense that a record apears two times in the database - because a hotel can have more than one room with the same attributes,

I agree.

so I chose not to throw any DuplicateKeyException.

Here I am not so sure.

Here is my interpretation:
On the one hand we must implement flexible solution which will easly allow relpacing db file to e.g. oracle where maybe rows have keys.
On the other hand our db file solution does not need DuplicateKeyException.
We could:
1. DuplicateKeyException extends RuntimeException
... and forget about it. If "junior programmer" will ask about it one day, we say "that's the bloody requirements we had to trick somehow".
2. Try to handle it even if it is not possible by our code to throw it keeping in mind that other db solutions can use it.

I lean more towards second solution.

Tom

[Mihai Radulescu]

Hi Tom,

Try to handle it even if it is not possible by our code to throw it keeping in mind that other db solutions can use it.

I agree with you, other DB solutions ca use it, thats why my DBMain intrerface use it, but in its specialisation(implemetation) for the actuale DB solution this exception makes has no real utility.
In my documetation I dont have any must or should related to this exception (on RecordNotFoundException I have).

Do you throw it ? What are your arguments for ?

Regards M
[ June 28, 2006: Message edited by: Mihai Radulescu ]

[Tom Nicki]

Hi Mihai,

Let's say you implement

DuplicateKeyException extends RuntimeException

and your code does not care about it.

Let's say there is a need to implement additional database accessor where keys are provided.
DuplicateKeyException gets important and it should be handled. How can you force that it will be handled by application using your new accessor?
Only by implementing DuplicateKeyException as checked exception but this destroys your previous application.

Du you want to copy/paste your interface to a new package implementing all exceptions from the scratch? I think interfaces should be reusable. Exceptions used in interface should be reusable as well.

BR Tom

[Mihai Radulescu]

Hi Tom


I don't understand you you ?
I'll try to explain what I do and correct me if I am wrong.

1.I have a DuplicateKeyException class and in my DBMain interface I throw this interface.
2.For the actual DBMain implementation - the Data class, I choose not to throw this exception because I don't find it useful(see the upper posts).

If in the future the database change I 'll need a new DBMain implementation (according with the new database solution), is up to this new implementation to use or not this Exception.


Regards, M.

[Tom Nicki]

What do you think about following code:

package suncertify.db;
public class Bc {
public Bc() {
DBAccess d = new Data();
d.createRecord(new String[] {""});
}
}

I guess you do not use it in this way.

Tom

[Mihai Radulescu]

Hi Tom

Well, I presume that the DBAccess is the interface(don't forget in interface the exception is throw) so this code fails by compiling because the Duplicate..
. is a checkable exception.

I don't use it exactly in this way but I still use createRecord method on a instance of type DBMain(DBAccess in your case).The method is in a try catch bloc
k.

I really don't see your point.
What you try to say ?

Regards, M.

[Miles Toliver]

Hi guys, thanks for all the insight. I am just in the initial phases of my analysis and had not really considered the points you brought up. You make a good point that it would be entirely possible for a hotel to have multiple rooms with the exact same data attributes. With that being said, I would probably lean toward the solution of having the interface define that the DuplicateKeyException is thrown and then perhaps not throw it in my implementation of the interface. I will need to review my assignment and see if there is any guidelines around this exception.

As for reusing a deleting entry, I suppose I could keep track of which entries are available (i.e. deleted) in the file and possibly use one of those, assigning the new record the same record id. The concurrency pitfall I was mentioning was that another client could be looking at old data that is not up to date and see a record number that reflects different information. However, this is likely out of scope for the assignment. Now that I think about it, my assignment does not mention giving clients the ability to add, modify, or delete rooms. It just mentions that the client must be able to search and assign a customer to an available room.
[ June 28, 2006: Message edited by: Miles Toliver ]

[Mihai Radulescu]

Hi Miles

Now that I think about it, my assignment does not mention giving clients the ability to add, modify, or delete rooms. It just mentions that the client must be able to search and assign a customer to an available room.

True, in my is the same. That why I have two type of clients : a simple one(book/search) and a advance (add/delete...) one. I provide UI only for the simple one.

Regards Mihai

[Tom Nicki]

Calling functions on the interface does not require me to know what kind of object it is. It can be Data. It can be also OracleData, XFileData etc.
It allows to use Facade, Factory patterns where a common parent (interface or class) is needed. It is just a question of polymorphysm and all its advantages.
And here comes the problem with DuplicateKeyException because calling createRecord on the interface requires to handle it.
If you use

Data d = new Data();

it probably makes your server implementation sticked to Data accessor.

It is your decision. Maybe correct one because easier to implement.
I still have some doubts.

Tom

[Mihai Radulescu]

Hi Tom

What make you think that I use the Data calss in the way how you describe it ?

Take a look on my post before :

Well, I presume that the DBAccess is the interface(don't forget in interface the exception is throw) so this code fails by compiling because the Duplicate... is a checkable exception.

I don't use it exactly in this way but I still use createRecord method on a instance of type DBMain(DBAccess in your case).The method is in a try catch block.

If a exception is declared in a interface you can :
1.throw the same exception
2.throw a subset of the specified exception - a subset can be also a empty subset.

With other words this is the impelmetation decision.

Regards M

[Tom Nicki]

Hi Mihai,

I think we will never finish this topic
I will try from the scratch and I give a simple example which shows our situation.

interface A {
void a() throws Exc;
}
class Exc extends Exception {
}
class B implements A {
public void a() {} // method does not declare any exception
}
public class C {
public C() {
A a = new B(); // (1)
a.a(); // (2)
}
}

You have 4 possibilites now:
1. put line (2) in try/catch block and handle "Exc"
2. you declare class "Exc extends RuntimeException"
3. in line (1) you use "B a = new B();"
4. You do not create class C at all
I described more-less pluses and minuses of solutions 1,2,3 and I cannot imagine solution 4 is not possible.

As you wrote somewhere before you "chosed not to throw any DuplicateKeyException". I guess it means your class implementing DBMain does not throw DuplicateKeyException and of course it is possible in Java (I assume you have something like class B in your sources).

And here I started to ask about your implementation and how "your class C" works. Which point (1/2/3/4) fits to your sources?

Is there any other way?

Maybe we should swich to priv emails? I have doubts it is interesting for anybody except us

Tom

[Mihai Radulescu]

Hi Tom

I use 1 (put line (2) in try/catch block)

Maybe we should swich to priv emails? I have doubts it is interesting for anybody except us.

How about an other thread with a appropriate title, maybe thare are also other people with the same problem like us.

Regards Mihai.

[Tom Nicki]

Hi Mihai

I think we do not have to create a new thread.
It is clear now and I have nothing to add.

Greetings,
Tom