Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S- Find method

 
Daniel Simpson
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The find method in suncertify.db.Data seems quite contradictory and confusing. In one part of the documentation it says,
It must allow the user to search the data for all records,
or for records where the name and/or location fields exactly match
values specified by the user.
However, in the comments on how the find method should be implemented it says,
A non-null value in criteria[n] matches any field value
that begins with criteria[n]. (For example, "Fred" matches "Fred" or "Freddy".)
The first comment makes the search mechanism both rigid and strict, although it earlier remarks about the importance of making
A data access system that provides
record locking and a flexible search mechanism.
I consider a flexible searching system returning and displaying "Freddy" when "Fred" was typed in. I think it can be frustrating for the user if they constantly do not get any search results because they didn't search exactly to the field value. Therefore, I think returning "Freddy" is permissable when "Fred" was inputed. This justification and solution will make the searching very flexible for the end-user. What do you guys think? I am violating that quoted must?
[ November 26, 2004: Message edited by: Daniel Simpson ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Daniel,

You might want to check your instructions again. From memory, the requirement for "exact" matches is in the GUI Client section, while the requirement for "starts with" matches is in the Data class.

I don't see anything wrong with such a specification. Consider it from a more "standard" software development perspective - you would normally get one programmer (or one team) to work on the server side, and a different programmer (or different team) to work on the client side. So the team working on the server side have specifications designed for greatest flexibility, while those working on the client side are working towards precisely what the end user expects to see.

Regards, Andrew
 
MF Tang
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking from another point of view,

It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user


is only a specific case (subset) of the

A non-null value in criteria[n] matches any field value that begins with criteria[n]. (For example, "Fred" matches "Fred" or "Freddy".)


so retrieve all the records starting with "Fred" will include the records that matches exactly with "Fred". So the exactly match requirement is still fulfilled.

Finally to have

A data access system that provides record locking and a flexible search mechanism.


I think providing the "starting with" search in the GUI is the most suitable.

Agree?

[Andrew: Changed all [CODE] tags to [QUOTE] tags]
[ November 26, 2004: Message edited by: Andrew Monkhouse ]
 
Kaz Yosh
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

Should we have six textfields to input criteria or just two for those name and location?

-Kaz
 
Anton Golovin
Ranch Hand
Posts: 527
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Daniel. I remember asking the same question, and I remember Andrew providing the answer (which removed a puzzling contradiction for me). I would like to digress, however, and add something related to the find method, which I think may not be easily identifiable even in testing.

When you find an array of record numbers, you will have to read them in. However, some of the records which partially matched and whose numbers were returned by the find method can be modified or changed before they are read. Therefore, when you read a record, you will need to actually recheck it to filter out possible non-matches. Here's where there can be a synergy between the need to recheck the records and the requirement for exact matches to be returned to the client.

Hope this is useful.
[ November 26, 2004: Message edited by: Anton Golovin ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kaz,

Should we have six textfields to input criteria or just two for those name and location?


Remember that the specification only requires you to have search capabilities on two fields, and that you will not get extra marks for going beyond the specification .

You should still write your search code (particularly on the server side) such that it is easy to add search capabilities for other fields later.

Regards, Andrew
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Hi Anton,

When you find an array of record numbers, you will have to read them in. However, some of the records which partially matched and whose numbers were returned by the find method can be modified or changed before they are read. Therefore, when you read a record, you will need to actually recheck it to filter out possible non-matches. Here's where there can be a synergy between the need to recheck the records and the requirement for exact matches to be returned to the client.


Very well put. Thank you.

Regards, Andrew
 
Jared Chapman
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By providing the user with two uneditable JComboBox's, populated with all the possible values for the respective fields in the database, a search will automatically return exact matches only (probably - explained later). The JComboBox's are populated when the client program is started, and never refreshed while the client program is running. At first, I was thinking of how I wanted to update these values in the event that records are added to/deleted from the database, but upon thinking further, I don't think this is necessary. The client program does not have the functionality to add/delete records, and the specs say that no other programs will be running (i.e. a database maintenence program).

It's possible that there could be a contractor called "Dogs" and another contractor called "Dogs With Tools", so if you really wanted to follow the exact match only instructions religiously, you could further filter the results returned from find to eliminate "Dogs With Tools" from the result set of a search on "Dogs".

One of the benefits of the JComboBox approach, other than showing the user the available values in case a CSR is suffering from CRS is that you would no longer have to worry about arguing case-sensitivity or white space in regards to "exact match", because you are providing the user with exact values.

Is my thinking reasonable?
[ November 27, 2004: Message edited by: Jared Chapman ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic