int[] find(String[] criteria) {}

Hi,
I've read in previous postings, that there is a difference between the
find method on the server:
int[] find(String[] criteria) {}
that is, the find() method associated closely with the database,
and the find algorithm used by the client. This difference being,
basically, that the database find() considers a match when the
field begins with the given criteria string, and the client-side
considers a match when the field and the criteria string match
exactly (as well as this version wanting the actual fields in the
record returned also). This is true.
However, I have also seen it posted that once one has the database
find() method running (the one Sun imposes on us, the "start's with"
version), that it is advisable, when writing the find() method that
entails exact matches, to use the previous Sun imposed find() version.
I have varied from this idea, and now present it, though this
presentation is not earth-shattering.
I defined two objects: Search and SearchResults. And, wrote a flexible
search algorithm taking into account everything I could think of that
I personally would find useful, including the ability to find MAX_NUMBER
of search results, and then go back in (after the user clicks on the
"next page of results" button) and get the next MAX_NUMBER of search
results.
This means that the client-oriented find() method does not use the
Sun imposed find() method. Instead, they both rely on the Search
and SearchResults object, and a new find() method which uses these
objects and returns results as directed to.
Aside: the improved find() method returns an array of Record
objects, and these record objects can be full (containing all the
fields of the record found) or sparse (only containing the record
number). Sun's imposed find() method requests that the Record[]
be sparse, and then simply ends thus:
return sparseRecords.toIntArray();
where sparseRecords is a Record[].
So, just pointing out another way to deal with Sun's imposed find()
method. Basically, this Sun imposed find() method, which really
isn't all that useful, simply set's parameters when it constructs
the Search and SearchResult objects to conform to the expectations
of what Sun's imposed find() method should do.
My client then calls the more powerful find() method using the
Search and SearchResult objects.
Thanks,
Javini Javono

Hi,
One thing I learned from the above is that using my find() method, and
controlling the looping, and dealing with the Search and SearchResult
objects, while not rocket science, is not trivial.
In contrast to this, using Sun's imposed find() method, was trivial! It
hides the details of the Search and SearchResult objects (though it
does not do looping, so, while it won't happen as an exam requirement,
if the file was very large, the JVM would run out of memory).
This was a great example of a facade pattern (if I have the name correct).
So, I will eventually attempt to write another find() method which hides
the details of manipulating the Search and SearchResult objects, as
well as the looping, and create another facade find() method which will
meet the requirements of the client (if it is possible to write such a
facade method, given that the client has a lot of options for the search).
Thanks,
Javini Javono