• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S 2.2.2 updateRecord()

 
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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".
 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 158
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 192
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 106
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Where all the women are strong, all the men are good looking and all the tiny ads are above average:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic