My question is Should the find method return the list of records that are fed to the jtable, rather than an array of record numbers?.
Joined: Sep 04, 2005
so you must after you call the find method re call the read method with all the records number return from find method , but the question that ask is : where you but these two call, in the server side or in the client side ?
Regards. Mohamed Darim.
Joined: Feb 18, 2008
First thank you for your reply.
To avoid the network overhead, I would prefer calling the read method at the serverside.
Assume Client calls
search(criteria)method of the Data.class
search method calls find(criteria) method
search method calls read(recNo) method from the for loop.
search method returns the matched records to the client.
Does this makes sense? [ March 14, 2008: Message edited by: John Mattman ]
Joined: Sep 18, 2006
Originally posted by John Mattman: The interface that sun provided me has a find method that returns an array of record numbers.
public int  find(String  criteria)
In my version of the assignment, I had a find method with this signature, too. I came to the conclusion that there are several problems with this signature:
1. For finding out whether a record matches search criteria, the record contents have to be read, and the client needs the record contents for displaying, too. So, it's a waste of resources first to read the record contents to get the record numbers of the matching records and then to read the records again on the basis of these record numbers.
2. Unless the whole database it locked while a search is made (which certainly would not be a good idea), it is possible that the database contents are modified by other users between the call to find(...) and the - potentially many - read(...) calls (even if everything is done on the server). So, the consequence would be that a) records with contents that do not match the search criteria any more may be displayed in the client's table and b) one might have to deal with RecordNotFoundExceptions for records that existed when the find(...) method was called, but have been deleted before the read(...) method for their record number is called. This can only be prevented if determining whether a record matches the criteria and getting its contents is done in the same operation.
3. The find(...) method in the interface provided by Sun does not have additional parameters for search options (depending on the spec such options may not be necessary, but in my assignment there was a mismatch between the description of the search between the client and server requirements as to whether only the beginning of the string or the whole field should match, so I made both search modes selectable by the client to be on the safe side).
For these reasons, I implemented a find(...) method with a different signature - instead of just the record number, it returns an object containing both the record number and the record contents (and it has additional parameters for the search mode). This method was used by the client. Since the find(...) method defined in the interface provided by Sun still had to be implemented, I simply delegated the call to my other find(...) method, retrieved the record numbers from the record objects that it returned and returned them as an array.