Originally posted by Jim Yingst:
Oh, you're making the search case insensitive? I had decided not to, but I suppose it could be justified the same way I justify returning both "Fred" and "Freddy".. My feeling is case insensitivity would be preferable in the real world (or better yet, a checkbox to choose whether to use it or not), but I'm not sure it's such a good idea here. I may yet flip-flop some more before I turn in my assignment.
FileChannel - yeah, that's what I use. Pretty simple really - it's just unfamiliar to most of us initially.
In the example you cite, the user can find the exact match of "Fred" - it just happens to be returned along with the inexact match of "Freddy". I don't see a problem with this; the requirements are vague enough IMO that this should be acceptable.
[Perry]: The requirements may be vague, but "exact-match" seems to me to be mutually exclusive to "nonexact-match."
I suppose you're right. It's not difficult to add a filter to take care of this, and it's only a slight increase in complexity - make the filter nice and modular, and clearly identify what it does and why.
If "exact match" is to be taken literally, then entering "Smallville" in the location field won't be valid for any records. Because all the fields have been padded with spaces to the length of the field and is part of the field value, strictly speaking.
Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.