Search exactly matches or partially matches?

Wanted to get a second opionion on this. The interface DB says searching is done with partial matching. So "Fred" matches "Fred" or "Freddy". The GUI specifications says "exactly match values specified by the user" So does this mean, from the GUI's point of view, that a search for "Fred" will only match "Fred" and NOT "Freddy"? Also, what are the thoughts on case sensitivity? should the GUI match "fred"?

hi Michael : very interesting point. My instructions was vague also. I solved this by implementing both functions. I provided the user with the option to search for exact string or partial string, but you don't have to provide the extra function.

SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle

I don't know what assignment you are doing but here is what I've done in the fly By Night. In the interface of DB they mention partial match for a certain flight but in the GUI they only want exact match. What I've done was a correction to the javadoc in the DB interface and done only exact match in the GUI part. If you read the instructions maybe you will find something wher SUN wants you to correct the DB meaning bug correction and javadoc corrections.

Maybe someone doing this assignment can give here a clue but to me looks like what I've done in FBN.

The problem you are facing is because you are implementing the "whole" project. If you were only tasked with implementing the server, or only implementing the client, then you would not see this as such a problem. So perhaps that is how you should look at working on this .

Your data access class is supposed to be designed for easy extendability / ease of reuse. So the architect of the Data class has asked for the find to do "starts with" type matching. No real problem there.

(By the way - I wouldn't go down the path of case sensitive / insensitive searches, or "contains" searches. The instructions don't require them, they would require extra method definitions, and you would be going beyond the specifications).

Then, when you get to the client GUI, you are writing an application which must meet the user's requirements. As such it is far more specific: it requires you to perform exact matching on the search criteria. Obviously, if you are going to be using the methods in the Data class, you must do additional criteria matching to reduce the "starts with" matches to "exact" matches.

If you had been given the job of writing the client application, and you were told that the Data class already existed and couldn't be changed, then you would find a way to do this. Work with that thought.

I also have the same issue with the Search functionality. I am busy with the Bodgitt and Scarper Version 2.2.2 assignment.

You have already answered one part of it, but I still have some more questions:

GUI Search Requirements: 1) "It MUST allow the user to search the data for all records": does this mean that the user "clicks" the "Show All" button and all records are returned and displayed? 2) "or for records where the name and/or location fields exactly match values specified by the user": does this mean that only records that EXACTLY matches the name and/or location is displayed after the findByCriteria method was called? Or, does this also apply to the other fields as specified by the user? The word "only" is not used, therefore it could be any field to be an exact match. Though they have used the term "and/or", they didn't use "etc."...? So, without the "etc." it could mean that the match must only apply to name and/or location.

Well since the GUI says it searches on name and location those are the only values I put into the GUI. My GUI does not allow searching on price, specialities, etc; ONLY name and location. When the results come back from the DB interace interface, My GUI code loops over the results and does a String.equals(String) call to get only those records that match EXACTLY. It is very common for clients to require records that are not quite exactly what a middle tier returns so futher filtering is required. Having a Find All button to get all the records is a good idea.

I provided another method for the name and/or location match. I implemented the findByCriteria method just for the sake of implementing, as no where in my specs had asked me to find records with values start with the criteria value.

Instead there is a requirement to find records based on name and/or location that exactly match the record values. I take it as the records returned had either the name that exactly match the criteria or had location that exactly match the criteria or had the name and location that match exactly. My method returned record objects directly and only accept the name and location as the parameter.

The specs only say that we need to create a Data class that implement the DBAccess interface only. It does not say that we must use all the methods in the interface right?

The use only the lockRecord and unlock methods in a class call DataManipulator, as for the rest of the methods, I just implement it according to the way the specs had described them but does not use them. After all the program that we are creating only needs to allow the Customer Service Representitives to book records not create, delete or update record, right?

You're right, the gui client does say only <b>book</b> clients, not add, update, or deleted. So there are methods that are implmented by Data.java but not used by the client. I think the gui should use the findByCritera() method and then GUI would further refine the results after they are returned.

Wickes Potgieter
Ranch Hand

Joined: Apr 05, 2002
Posts: 68

posted Jun 30, 2004 12:39:00

0

But surely you need to use the update method when you do a booking?

Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124

posted Jun 30, 2004 19:19:00

0

But take a look at what information is updated when user books a record - it only needs to set the customer id only, so why commit the change to all the other unaffected values? It is more inefficient for the dataserver also. If you use update to book a record, It will be at least 6 times more inefficient and it is not worth the cost than just updating one value.

Furthermore in server mode, you may have a lot of clients connected, the inefficiency will be even more significant.

(By the way - I wouldn't go down the path of case sensitive / insensitive searches, or "contains" searches. The instructions don't require them, they would require extra method definitions, and you would be going beyond the specifications).

It is possible to easily do case-insensitive searches, which I think are user-friendly, and no additional method definitions would be required.

I agree with Clivant, that one should not unnecesarrily update the complete row if only 1 of 6 values is changed. I used the update method to update only the owning customer for the given row, and did not provide a way to update the remaining columns in records, such as Size.

I set it up so the inconsistencies are a non-issue (I actually posted this ? about a month ago).

I have drop down boxes for the Contractor Name/location and I implement the starts with searching on the server side. Obviously, by sending in the exact Name/Location, I fulfill the client side requirements while fulfilling the server side (Data) by searching for inexact matches.

But take a look at what information is updated when user books a record - it only needs to set the customer id only, so why commit the change to all the other unaffected values?

I not only use the update method for booking, but after I do a book, I completely redo the last search. I'm sure you would consider this very inefficent, but remember that you are working in a multi threaded environment. It's nice to keep the user somewhat in sync with what everyone else has booked since the last time he hit search button. Not to mention what happens when someone else has already booked the record in question - you don't want a error dialog to appear, but your search results to sill look like it should have worked...

About the Exact Match, does this mean "Fred" does not match " Fred" or "Fred "? Do i need to eliminating the spaces around them before matching because sometimes the user may type an extra space after or before a hotel name or location.

It is generally accepted (at least I've never seen it otherwise in 8 years of professional software development) that leading and trailing spaces be stripped from database searches except in those situations where they clearly are relevant (such as in some scientific data, which would usually not be searched on directly anyway).

Well let me tell you want I did, which is apparently correct because I passed my exam.

First, with regards to leading and trailing spaces. I always strip them out as part of a data verification process done in the GUI before sending the search to the "middle tier". Because the data file is stored as bytes, the implementing DB class must automatically handle trailing spaces. So "Michael " must be stored to the file to keep the number of bytes correct but it's easier to just deal with "Michael" in the application.

I implmented the DB search exactly as the javadoc says. I return partial matches and ingnore case. I also implemented the GUI exactly as the instructions says. So after the DB class returns, the GUI loops over the results and picks out only exact matches.

What's confusing me is what should happen if I pass in say {"Bitter","Stoke"} for name and location. Where "Bitter" is a partial match, but "Stoke" doesn't match. Should I return all the correct matches for "Bitter" (OR implementation) or none because or the false "Stoke" match (AND implementation)?

Also the line "Field n in the database file is described by criteria[n]" suggests the equality test should be: field[1] == criteria[1] etc.

However, the line "A non-null value in criteria[n] matches any field value that begins with criteria[n]" suggests that: field[1] == criteria[n]

i.e any field can be matched to any criteria.

For my part I've implemented the OR implementation that searches on any correct field. Has anybody else implemented it this way or have they gone for the other options?