Originally posted by Clivant Yeo:
I think it is wise to follow the documentations stated by the DBAccess interface for the method. For my case, the documentation of the DBAccess interface for the findByCriteria method cannot be used for my search function based on my name and location field. What I did was to provide a separate method to be used for the search function based on name and location fields and implemented the findByCriteria method according to the specs.
I guess it is better to implement the methods of that the Data class inherits from the DBAccess interface according to the specs. If they can't be used, just don't use them, create other methods that suit your function needs. I guess after all the rules is not violated when you implemented the methods but don't use them rite?
[ September 09, 2004: Message edited by: Clivant Yeo ]
There are two ways to do the business find method that rely on the DBAccess find method:
1) use the DBAccess find method to get the record numbers of all partial matches. The required records will be a subset of this. In your business logic, read these records and filter out the ones you want.
2) define the findByCriteria method to do a partial match padding the data with binary zeros to the length of the provided key. If you do this the
string "Fred\0" will match Fred, but not Freddy.
The AND match can then be done directly using the DBAccess interface. If you want to do the OR match you get the set that match the name and the set that matches the location and do a union on the sets.
Regardless of how you do the matching, you probably should refilter the data before displaying it in the client as it may have changed between your find and read.