aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S 2.2.2 updateRecord() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S 2.2.2 updateRecord()" Watch "B&S 2.2.2 updateRecord()" New topic
Author

B&S 2.2.2 updateRecord()

Pete Palmer
Ranch Hand

Joined: Oct 21, 2008
Posts: 74
Hi

The following is my spec for update :-

My approach to this interface is that I have specified that the String array must hold 6 elements - name, location, specialities, size, rate & owner respectively. Only the owner element is permitted to be empty ( not null ).
This interface is used to book a contractor and in this case all elements will hold non empty strings and will be wriitten into the database, overwrittening the original record. I would have used this interface to "un book" a contractor but this is not required.

If Sun's test harness uses this interface with a valid recNo and loclCookie and fulfill the specfied constraint for the String array, I will overwrite the specified recNo record with the new detail.

RecordNotFoundException is raised if recNo is invalid. SecurityException is raised if the lockCookie value is not the correct value for recNo.

Is this approach on the right line ?


Pete
Kevin Florish
Ranch Hand

Joined: Jan 06, 2009
Posts: 163
Hi Pete

I am working on B&S 2.2.1, which i am sure is pretty similar to your project.

I have adopted a similar approach although when updating a record I do a couple of checks:-

1) Make sure the rec no actually exists in my locking map.

2) Check that deletion flag isn't set to deleted.

With regards to Unbooking I took the approach that it must be reasonable at some point to unbook a contractor. Of course this is a business decision and I will include this choice in my choices.txt document.

Regards Kevin.


Java5 Tutorials | Java6 Tutorials | HTML/CSS Tutorials | JavaScript and jQuery Tutorials
Pete Palmer
Ranch Hand

Joined: Oct 21, 2008
Posts: 74
Kevin,

Thanks for the feedback. Always good to know that one is on the right track.

Like yourself, I have map which holds all valid record (recNo to fileLocation ), which should effectively tell me if the recNo is valid or not. Checking if a recNo is valid against the above the map should detect the case when attempting to update a deleted record - simply because it would not be in the map.

However, this is probably a good case to perform the delete flag check and use the "assert" if detected ie. this condition should never occur and highlight a design flaw !!

Thanks

Pete

Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53
Hi Pete,

What if somebody want to update rate field only, in that case all others have to be null, you are allowing only owner field "null",

If you make it little more flexible(update any non-null value !) you can use it to book a record. Just send a string array to update method with "owner value" and rest as null.

moreover, according to your specifications "field n appears in data[n]. " , "n" means 'any': n can be '6' which is owner field.

Alain
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
Alain Dickson wrote:What if somebody want to update rate field only, in that case all others have to be null, you are allowing only owner field "null"

There's no spec saying that "all other fields have to be null".


SCJP 1.4 100%
SCJD 99.5%
Pete Palmer
Ranch Hand

Joined: Oct 21, 2008
Posts: 74

My spec is

// Modifies the fields of a record. The new value for field n
// appears in data[n]. Throws SecurityException
// if the record is locked with a cookie other than lockCookie.
public void updateRecord(long recNo, String[] data, long lockCookie)



The spec is not clear on the String [] so I decided to specify what this is thus keeping the implementation & testing simple. Naturally will document this.

So many people have said keep it simple and so I am taking that approach.

Alain, your approach is obviously is not wrong.

Pete

Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53
Pete:
Well keeping it simple is the first rule as long as you are fulfilling DBMain contract, I wish I could justify to myself to keep the update method that simple.
when your specs say field[n] it says it can be any field even if does not say anything about String[].
I think if you do not let any of the fields get updated thorugh update method it do not fully fulfills the interface contract.

Alecsandru: Yes, specs do not say that, It just came out how I did it. My update method updates any non-null field.
My Question to Pete was only the first part: What if somebody just want to update the reate filed? how do you set other fields in the string which are not updating?

Regards,
Alain
Alecsandru Cocarla
Ranch Hand

Joined: Feb 29, 2008
Posts: 158
Alain Dickson wrote:Alecsandru: Yes, specs do not say that, It just came out how I did it. My update method updates any non-null field.
My Question to Pete was only the first part: What if somebody just want to update the reate filed? how do you set other fields in the string which are not updating?

Simply: when you update a record, you have all its fields as you'd want them to be after the update. Just set all fields of the String[] to the values from this updated record and write the entire record to the database, not only the fields which are really changed. So no need for this rule that you should update only the non-null fields. Write everything. This keeps things simple: you don't have to check which records are really changed, and you can use the same writing algorithm for update and create.
Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53
Even then, you must check all the fields of the incoming string array to make sure required fields are not null/invalid which can spoil the record. This check is due deligence of update method.
NOW if you are already checking the incoming array for any null/invalid values, THEN why not use the update method for updating non-null values which will be more flexible with almost same amount of work.
However:
Alecsandru Cocarla wrote: you don't have to check which records are really changed

I do not check a non-null value if it has really changed or different form the one already in file, If a value is recieved it will be written to file, Assuming if updater sends a non-null value he/she wants to be written it to the file. BUT if I am using the algorithm "update non-null values" I can use the update method for both create and book functionalities.

Regards,
Alain

Kevin Florish
Ranch Hand

Joined: Jan 06, 2009
Posts: 163
I am not checking field values in updateRecord() maybe I should

I just think that these values would be checked in the GUI prior to calling the updateRecord() method.. and therefore my assumption (probably wrong) is that by the time we get to call updateRecord() all fields are validated.
Pete Palmer
Ranch Hand

Joined: Oct 21, 2008
Posts: 74
Gents,

As described by Alecsandru :- my update is like this


For valid update of rate & location field, data [] would contain
where the responibility is really on the client to provide all the information.
This approach will allow any field to be updated, as long as the other
unchanged fields as provided and meets the requirement that the
new field will be in data[n]


What I don't support is an update location & rate where data [] has null for the unchanged fields.

I appreciate this is more flexible, but I don't think it is a "must".

My create record is identical to the update



NOW if you are already checking the incoming array for any null/invalid values, THEN why not use the update method for updating non-null values which will be more flexible with almost same amount of work.

Not sure what you mean here Alain.

Alain, you support "{ null, modified_location, null, null, modified_rate, null}", so do you make two atomic write operations to write each field into the file or read orginal record, update and write the update record back ?

Alecsandru, did you take a similar approach to mine ?

Thanks

Pete




Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53
Pete wrote: Alain, you support "{ null, modified_location, null, null, modified_rate, null}", so do you make two atomic write operations to write each field into the file or read orginal record, update and write the update record back ?


Here is what I do:


The difference I see in your and my update is that you do not allow the user to send only one value if the user just want to update eg: rate and user have to send all the values even if only one needs to be update. But I aceept one or more values (but less than total fields of database). Since I allow update method That flexibility I am using it to book a record as well and create method also deligates some of its job to update, as create is also a kind of update. Since you are keeping it bit simple you must be writing an extra bookRecord method.

I guess as long as it is jutifiable it is fine as we both are achieving the goal.

Regards,
Alain

Pete Palmer
Ranch Hand

Joined: Oct 21, 2008
Posts: 74
Alain,

I guess as long as it is jutifiable it is fine as we both are achieving the goal

Couldn't agree with you more.

Pete
Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53
I felt that before you, thats why I said
I guess as long as it is jutifiable it is fine as we both are achieving the goal


But, make sure your implimentation agree to this line of your specs
// Modifies the fields of a record. The new value for field n
// appears in data[n].

Good luck,
Alain
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S 2.2.2 updateRecord()
 
Similar Threads
Cookie value used in DBAccess Interface
DBAccess.java
Lock question!
RMI confusion
No definition of what is a DuplicateKeyException