• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S Nulls in update method argument:data[]

 
Mary John
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all

I have some questions about the update method arguments. Some of you might be able to help me here.

my update method 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)
throws RecordNotFoundException, SecurityException

Nulls in array
1. I am allowing nulls to be in the data array. If nulls are present then
it means that the field does not need update. If there is a value in the string then that field is updated. Is this a good approach? or Do you think that nulls should not be allowed and some value should always be present?

Length of data array
2. I allow the data array to be of 'any' length(more than or less than number of fields) and the method appropriately handles it as follows:
.. if data array is less than number of fields then, only that many fields are updated. if data array is more than number of fields then those elements outside the range of number of fields(example 6) is ignored. Is this a good appraoch? any thoughts.... please?

3. Length of string in data[] can be any size
if length if string is more than maximum size, I would just take the number of characters that is allowed and if it less I would padd excess space with whitespace. How is this approach

Please let me know if these approach is ok.

Thanks in advance
Mary
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy, Mary.

Based on:

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

Nulls in array
I don't think accepting nulls in the data array is a good idea, because the statement says that "the new value for field n appears in data[n]". Maybe, throwing an IllegalArgumentException in case of null values could be a good idea here.

Length of data array
I think the length of the array should reflect the reality of your database. So, in my opinion, it should be the same size as the number of columns that the database has. Maybe, throwing an IllegalArgumentException in case of different number of columns could be a good idea here too.

Length of string in data[] can be any size
In my opinion, your approach is perfect.
 
Mary John
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks roberto. I agree to your approach, and it make coding easier and eliminates unnecessary complications.

I have still one doubt left about not allowing nulls for the data[] array.

" the new value for field n is present in data[n]",

So if we wanted to update only one field, then do we send the previously read data for remaining old values plus the new value?

I mean,For example

In my book method

-call read method and get the latest record values as {oldvalue1, oldvalue2, oldvalue3,oldvalue4,oldvalue5, oldvalue6}

-construct data[] array as {oldvalue1, oldvalue2, oldvalue3,oldvalue4,oldvalue5, newvalue6}
-send this data[] to the update method

Thanks
Mary
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy again.

So if we wanted to update only one field, then do we send the previously read data for remaining old values plus the new value?


That's it!
Good evening!
[ March 26, 2008: Message edited by: Roberto Perillo ]
 
Mary John
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks .....got it..
 
Jon Park
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roberto & Mary,

Don't you think you need to allow null values, since you might want to set certain fields to null? (the owner field, for instance. <- unbooking)
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jon Park:
Roberto & Mary,

Don't you think you need to allow null values, since you might want to set certain fields to null? (the owner field, for instance. <- unbooking)


Partner, since an unbooking function was not required, I didn't even consider that.
But what I did, I allowed only the customer ID field to be null, since I considered that all other fields are mandatory for a record. The customer ID isn't. This is how my update() method works.

Now, to Mary:

I thought again about your statements above... and here's a second thought:
I think it is ok to accept null values in the String [] that represents a record. But in this case, I think it would be appropriate to only update the values that are not null (since I think all fields, except for the customer ID, are required). And also, I think it is ok too to accept a String [] where its length is <= the number of fields of a record. For example, we can tell "Update Table Set Name = 'Mary', Location = 'JavaRanch' Where PrimaryKey = 1". It would only update the given fields, and there would be no need to point the other values. So, I think it would be equivalent to accept a String [] that has just the fields that need to be updated.
I implemented the update method this way, I check all fields, and I don't allow null values (except for the customer ID). This was my approach. I forced this because I considered that all fields are mandatory. And also, I think this approach is simpler: since such a special update() method was not required, I thought this would be the best way to implement it. My approach for the entire application was to keep things as simple as possible, and to only implement what was extremely required. But your approach is equally correct. All we must do is justify our approach, and that is totally ok.
[ May 08, 2008: Message edited by: Roberto Perillo ]
 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nulls in array

I think allowing nulls is no problem. The find function allows nulls, so it is good to have uniformity. The only thing is you have to document your choice.
I didn't allow nulls.

Length of data array
I think the approach is ok. I did almost the same, except that with less fields I fill the missing fields with spaces. And with surpluss fields, a warning is logged.


3. Length of string in data[] can be any size
I did the same. I log a warning if too much chars in a field.
 
rinke hoekstra
Ranch Hand
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roberto Perillo:

Length of data array
I think the length of the array should reflect the reality of your database. So, in my opinion, it should be the same size as the number of columns that the database has. Maybe, throwing an IllegalArgumentException in case of different number of columns could be a good idea here too.

Length of string in data[] can be any size
In my opinion, your approach is perfect.


Hi Roberto,

Isn't this a bit inconsistent? I mean: with too long arrays you throw an IllegalArgumentException; with too long fields you just cut off surplus characters.
Wouldn't the same kind of handling in both cases be more consistent?
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey partner.

Originally posted by rinke hoekstra:
Isn't this a bit inconsistent?


Well, it's all about choosing and justifying. That's the way I did, I check if the length of the array equals 7 and if it isn't null. If one of these conditions fail, I throw an IllegalArgumentException. And I just allow the customer ID to be null. I made this choice because I think this is the simplest way to implement it. And I also cut off the exceeding characters before persisting each record. But if you choose to implement the update method in a different way, it is equally ok. Just justify what you are doing and that's a-ok.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic