URLyBird Data Access Package Design

[Bharat Ruparel]

Hello,
I am a new member of JavaRanch. This is a fantastic forum which facilitates learning and certification process very effectively. I am currently working on the Developer's Exam project. I have gotten the URLyBird version 1.3.1 assignment. I have also purchased Max's book and have read through it in detail. I like the layered design approach presented in his book and want to pursue it unless otherwise advised for a good reason. I just want to run my understanding of design presented in his book by the group and see how it can be adapted for the URLyBird project. Any comments from anyone are appreciated.
I am currently focusing on the design of the Database Layer identified in Max's book by the package SampleProject.db in his version 2.0 implementation. It has the following four classes (excluding the DOSclient.java class which belongs to version 1): DBClient.java (interface), DVDDBAdapter.java (implements DBClient interface and contains a private reference to: ), DVDDatabase.java, and finally DVD.java representing a serializable widget that is stored in the database.
If we compare this to the URLyBird assignment then I see the following mapping between the two: First the package suncertify.db compares directly to the package SampleProject.db in Max's book. Next, the required interface given under the section Server in the assignment called DBMain.java directly compares to the DBClient.java interface in his book. Next, the assignment states that this interface must be implemented by a class called "Data.java"; will it then correspond to the DVDDBAdapter.java class? If yes, then I need to create another class that does the work of DVDDatabase.java class in Max's book (I am thinking of calling it simply Database.java). As in Max's book, the Data.java class will contain a private reference to Database.java and delegate the actual work to be done to it (so far so good?). What will then correspond to DVD.java class? Is it an instance of Room.java (short for Hotel Room)? If yes, then there the interface DBMain.java is NOT really defined in an object-oriented manner. Rather, it definitely has a File/Record orientation. There are several questions that come to my mind. For starters: all the CRUD (create, read, update, delete) methods communicate with the database using Record Numbers (recNo) and return/send the instance data as an array of String rather than as an instance of Room object. Any problems with that? Next, if you consider the definition of the create method given in the interface (public int create(String [] data) throws DuplicateKeyException. My question is: what is the unique key here? is it the ID of the customer holding a room? Does it mean that there cannot be two records (not deleted) in the database with the same customer ID? Who generates this key? My program? Next, the interface also has all the locking methods, e.g., lock, unlock, and isLocked. As in Max's book, I am thinking of implementing the methods in Database.java class with Data.java adapter class simply delegating actual work to it, sounds good?
Let me know what you think.
By the way, on a different topic, the database schema presented in the Data File Format is a bit flawed (unless somebody corrects me here). I found that third field defined from the top, i.e., Maximum occupancy of this room (database field name is size) has a field length of 4 giving the impresssion that it is probably stored as an int. Not so, when i read it using RAF.readInt() method (RAF stands for RandomAccessFile), I got the ASCII value of the numbers. When I read it as a fixed-string that is 4 characters wide, I got the right result. Another thing to be aware of is that the deleted flag before the start of the actual record must still be read as a single byte using RAF.readByte() method. I found the following method very useful when reading the records off the file and am posting here since I see many posts that seem to be floundering around the same issue. I am not trying to give the code away, simpy pointing the gotchas and giving the basic building blocks.
static String readFixedString( RandomAccessFile p_in, short p_size) throws IOException {
StringBuffer b = new StringBuffer(p_size);
int i = 0;
boolean more = true;
while (more && i < p_size) {
char ch = (char) p_in.readByte();
i++;
if (ch == 0)
more = false;
else
b.append(ch);
}
p_in.skipBytes(p_size - i);
return b.toString();
}
Regards.
Bharat Ruparel

[Mark Spritzler]

Welcome to JavaRanch, Bharat. Congrats on taking on the assignment and wish you good luck and we are all here to help.
Mark

[Bharat Ruparel]

Thanks Mark. Phil is already helping me getting off the block. You guys are great.
Since my first post here, I have been browsing through the forum and am beginning to see some answers to my own questions: It looks like Max has answered the questions that I raise here on the Post "No need for a locking manager?" Here is the quote where I think he answers these questions:
"Regardless of where it should be from an aesthetic level, my feeling is that Sun intended for the locking control to reside inside Data, because they put the locking method signature inside the Data class. Thus, I think you're coloring outside the lines a bit if you don't do that. This is just my opinion, of course. But I think Data is really supposed to be your low level DB API.
Further, I don't think that Data class should be dependent on the connection class at all: As a matter of fact, I don't think that Data should know anything at all about the Connection class. nadda, zip, zilch. IMO, Data should simply be a private member variable of what you're referring as the Connector class(I might refer to it as a Mediator or Adapter). Thus, Connector has a method called, say, lockRec. internally, the lockRec method uses the private member variable Data(one per Connector) to lock the record.
In this scenario, you don't need a lock manager at all, because the Data object handles it's own internal problems and conflicts, like a good object is supposed to. The way is does this is through a static Hashmap. The role of Data here is to make the Connector(Adaptor/Mediator, whatever), feel like the world is simply, sun shiny place to be, and that complexity is just a bad dream. This way, Connector can just be a happy, go lucky, simple remote object."
Reading through this I realize that here is the correspodance between URLyBird and Max's DVD Project
----------------------------------------------
data.java corresponds to DVDDatabase.java
Need to create an adapater class (DataAdapter.java?) in URLyBird which does the job of DVDDBAdapter.java in Max's book.
Sounds good?
I don't know why people didn't respond to this thread? May be I need to be more precise?

[Philippe Maquet]

Hi Bharat,

I don't know why people didn't respond to this thread? May be I need to be more precise?

Maybe yes ;-) (in this thread anyway, because you saw in other ones of you that people reply to you !)
About the locking, I would say yes, Data must be responsible for it. It means that it must at least be the entry point of any lock/unlock method. It doesn't go against a LockManager class (one solution among other ones), because if you use one, Data just delegates its job to it (for the external world, Data is the only visible class if you prefer). You may apply it for other "data stuff" : if you implement a cache, you may decide to code all the caching stuff in Data itself or decide to create some DataCache separate class (package level) because you feel it easier to design and maintain. It's just personal taste.

Thus, Connector has a method called, say, lockRec. internally, the lockRec method uses the private member variable Data(one per Connector) to lock the record.

I suppose that what you call "Connector" is what I call my business tier (which has no name yet for me ). If it's the case, I think that some "lockRec" method is to "low-level" for it. In URLyBird, I just see two methods : book() and find().
Best,
Phil.

[Bharat Ruparel]

Thanks again Phil.
Bharat

[Bharat Ruparel]

Hello Phil,
I am back with follow-up questions. In early bird assignment (I have URLyBird 1.3.1). It says that data.java must implement DBMain.java Interface. Further, the interface shows create method as throwing DuplicateKey exception.
My question is: what is the key here? is the Record Number? The reason I say that is that the return value of create is shown as int. Moreover, the remaining CRUD methods, i.e., read, update, delete all take Record Number as a parameter. Will the system (meaning my program) generate the record number? Is it simply the number of existing records in the file plus 1 ? Since record number is not explicitly stored in the file, how can there be a duplicate key violation?
Bharat