B&S createMethod()

[Pete Palmer]

Hello,
I am just starting on the B&S assignment (2.2.2). Below is the create method

// 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;


Few questions that I hope you can help me with please.

1) The data array will contain 6 string elements and in this order :-
[0] - Subcontractor name ( 32 bytes )
[1] - location ( 64 bytes )
[2] - specialities ( 64 bytes )
[3] - size ( 6 bytes )
[4] - rate ( 8 bytes )
[5] - owner ( 8 bytes )

a) Is this a valid assumption ?


2) All 6 element have to be present and only the owner element string can be "" - empty ( not NULL ).

All other elements need to have some content because, in my opinion, a record can only valid with all the contractors detail.

a) Is this a valid assumption ?

3) The data layer design uses the Facade pattern, which use the Adapter pattern to provide the interface to the database file.


public class Data implements DBAccess {


/**
* The class that handles all our physical access to the database.
*/
private static DatabaseAccess database = null;

....
....

public long createRecord(String[] data) throws DuplicateKeyException {

database.createRecord( data );
}

}

a) Any exceptions raised in the database.createRecord() will require to be wrapped up in DuplicateKeyException ?

This exception require to be handled by the Client ?

b) Under what scenario would a DuplicateKeyException be raised in the createRecord () ?


4) Some questions on the implementation of the database.createRecord( )

a) The method description suggests "(possibly reusing a deleted entry)". I presume this means I need to maintain a list of records that are marked as deleted and re use them in the createRecord( ).
And if there are no deleted records, I just append the new record to the last one in the file.

b) There is no requirement to inform clients of the new record created ?


Thank you

Pete

[Alain Dickson]

Hi Pete,
I am working on B&S 2.3.2. I am still in System analysis and design mode.
Only place in assignment document which indicates that a create method needs to be implimented is the interface structure, but in now way GUI uses this method. More over this applications is for CSRs who will not be using delete/create record functionality.

I mean to say that do we need to implement code in this method, OR just to fulfill the contract of the interface we can implement this method as empty with comments like " to be implemented in future etc..".


Thanks,
Alain

[Pete Palmer]

Hi Alain,

You correct that there is no need to the create record behaviour from the GUI. However, I think I would like to implement all the methods on the DBAccess interface. So I need to understand how to interpret the parameter "Sting [] data" on the createMethod and also for updateRecord().

void updateRecord(long recNo, String[] data, long lockCookie)
long createRecord(String[] data)    

Do you have any suggestions please ?


Thank you

Pete

[Liviu Carausu]

Hi Pete,

a) Any exceptions raised in the database.createRecord() will require to be wrapped up in DuplicateKeyException ?

I will use a "not checked" exception instead of misusing the DuplicateKeyException.

[Alain Dickson]

Hi Pete,
To interpret the string data you need to use getByte() method of string class, which gives you array of bytes and then you know what to do with it.

one more thing: I noticed "long recNo" argument in argument list of your updateRecord method. Data file schema do not allow any field for record number. If you insert a record number, would't it alter schema of the file.

Regards,
Alain

[Pete Palmer]

Liviu,
You suggestion of reporting unchecked exception, would you expect the exception to handled on the client side .. possibly generating a "pop up" error message. I have not looked the GUI but this is just a thought.


Alain,

To interpret the string data you need to use getByte() method of string class, which gives you array of bytes and then you know what to do with it

I am still struggling with this idea of treating the array of string parameter as bytes. Why wasn't the parameter just an array of byes !!.

Ok so if I treat the parameter as an array of bytes, is the structure of the array of bytes as follows :-

bytes Field
0 - 31 Subcontractor name ( 32 bytes )
32 - 95 location ( 64 bytes )
96 - 160 specialities ( 64 bytes )
161 - 167 size ( 6 bytes )
168 - 176 rate ( 8 bytes )
177 - 185 owner ( 8 bytes )

Please clarify.

As to your question w.r.t "long recNo", this identifies the record that needs to be updated. So if for example, you have 5 records :-

record number
1 record 1
2 record 2
3 record 3
4 record 4
5 record 5

And the user wants to update record 3, than recN will be set to 3. The recNo does not have to be stored in the database. I guess that I assuming the recNo starts with 1 not 0 should be documented.

You will probably use the recNo to identify client that has booked a service.

Pete

[Alain Dickson]

Hi Pete,

Why wasn't the parameter just an array of byes !!.

It can be(you can make your life easy that way), but in future if somebody is using this method to create record(We dont have a requirement in our assignment to create a record), Has to convert a String to bytes, because when a user enters information to create a record(future consideration) it will be treated as string in the frist step:

So you can do two things:
1. You can just accept the butes array as parameter and it will be upto the future programer to suppy that byte array(Thinking it a real life scenario)
2. You can accept String array and do the work, in which case future enhancements won't require much of work or thinking, the future program will just pass get the string from the user, put it into array and pass it to your create method.

Ok so if I treat the parameter as an array of bytes, is the structure of the array of bytes as follows :-

bytes Field
0 - 31 Subcontractor name ( 32 bytes )
32 - 95 location ( 64 bytes )
96 - 160 specialities ( 64 bytes )
161 - 167 size ( 6 bytes )
168 - 176 rate ( 8 bytes )
177 - 185 owner ( 8 bytes )

Yes thats right if you have concatinated whole information into one long array.

[Pete Palmer]

Alain

So you can do two things:
1. You can just accept the butes array as parameter and it will be upto the future programer to suppy that byte array(Thinking it a real life scenario)
2. You can accept String array and do the work, in which case future enhancements won't require much of work or thinking, the future program will just pass get the string from the user, put it into array and pass it to your create method.

Point 2, each string passed will need to padded out to the appropriate array size, I presume ?

I have looked in the forum to substantiate your suggestion and found nothing. I will sleep on it for a few days and if it still prays on my mind, I might have to ask the forum again.

Pete

[Alain Dickson]

Pete,

Not only you have to pad the array according to the data file schema but as per requirements you have to null terminate every field if it is less than the total length.

FROM Requirements: All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field.

If you find anything from the forum in future, send me a message if possible, I will also start coding in few days.

Alain

PS: What ever i have said is my understanding and my experience, you don't have to belive it, these discussions are just to stimulate insights.

[Roberto Perillo]

Not only you have to pad the array according to the data file schema but as per requirements you have to null terminate every field if it is less than the total length.

Well, yes... but I have added extra spaces to each field so it has the same number of characters as its size. So, for instance, if a field can have 64 characters, and the value being saved has 30 characters, then the final value that will be persisted is 30 characters + 34 extra spaces. I justified that I wanted to keep the current database structure.
[ December 12, 2008: Message edited by: Roberto Perillo ]

[Pete Palmer]

Alain,

I get the impression we are both at a very early stage of our assignment and throwing ideas between us is great, however, we could be just barking up the wrong alley. I just a think our thoughts need to be rubber stamped by an experienced rancher.
Which assignment are you doing ? I am doing B&S 2.2.2.
Of course, if see anything useful on the forum, I will inform you.

Roberto,
I presume, you also treated "String [] data" as a ONE long data aray, BUT, you don't NULL terminate the string as per the databse structure which is fair point. And yet Alain, has quoted the requirement that it has to.

How can we tell which is the correct approach ?

I am just disappointed that the interface has not got a clear meaning !!


Pete

[Alain Dickson]

Hi Pete,

I have B&S 2.3.2

As far as null termination of the data file fields is concerned, I am QUITE SURE that we should null terminate them. The assignment document says that we are not allowed to change the database schema SINCE other applications will be accessing the data file to generate thier reports, Those applications may be using null termination as part of their logic to read the file.

FROM ASSIGNMENT: The company's IT department has a data file that contains the essential information for the company, but because the data must continue to be manipulated for reports using another custom-written application, the new system must reimplement the database code from scratch without altering the data file format.

Roberto: What do you say, did you get full score for server implimentation? Since you have already got your result.


Alain

[Roberto Perillo]

To Pete:

No, I do not treat the String array as a unique String, I persist each field separately (is that what you're asking? ). Also, this rule is not exactly related to the database structure, but how you should deal with a value that has less characters than its maximum size. If you look at the current data in your database file, you'll see that the fields do not have null terminators, but extra spaces. However, this was my approach; if you want to go ahead with the null terminators, go for it. Just make sure you can read both records that have null terminatos and extra spaces.

To Alain:

Locking: 80 80
Data Store: 40 40
Network Server: 40 40
[ December 12, 2008: Message edited by: Roberto Perillo ]