This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLBird find by Hotel or Name Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLBird find by Hotel or Name" Watch "URLBird find by Hotel or Name" New topic
Author

URLBird find by Hotel or Name

Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi,
We have to supply three types of search by URLBird asignement:
"to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user"
and
"the search mechanism should be flexible..."
At the moment I have three method for each one. The most terrible is "OR"
search:
1 put all found record numbers by hotel record numbers in Set
2 put all found record numbers by location record numbers in Set
3 read all records for found record numbers
4 Transfer all record numbers from Set to array
5 filter records since search criteria
in client differs from the one on the server
In future if more search criteria fields for search desired (e.g. Customer, Date etc.) it will even more ugly. I would to invoke separate search from DB /DBAccess interfacer so many times as criteria fields.
It doesn't matter where the search implemented in client or in business server (Adapter class in case of 3-tier architecture), since the use anyway
DB interface:
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int[] find(String[] criteria);
I thought about using regex, but it doesn bring a lot.
Does anyone know a more elegant solution?
Tx,
Vlad
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
My Interpretation is slightly different, as given by my interface below.

The interface suggests that the find method should compare all fields (Not just location and name), and a null value matches everything for a particular column.
In the GUI implementation we just use the location and name to do the search. This implicitly means that we provide drop downs or seach boxes for location and name in the GUI.
So you need only one search meathod.

- SB
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi S,
Not really:
We have to differ "AND" search and "OR" search, since they must return different results:
Example:
database
hotel1, location1
hotel2, location2
search criteria
hotel1, location2
results by "AND" search
nothing
results by "OR" search:
hotel1, location1
hotel2, location2
The specification is VERY CLEAR on this issue!
Vlad
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
Hmm. Put me into some thinking there...
I beg to differ though.
name AND/OR location search
OR means
1) user just gives only one value. either name or location
And Means
1) user gives both values. name and location.
***********************************************************
let us take your example.
if we go by what you are saying there are 2 ways..
a) we provide another option in the GUI - to choose AND/OR search.
b) we do a AND search first, if don't find anything do the OR search.

if we look at all the commercial web sites, the options for drop downs are mostly "AND" based- for eg. a city and state search. Besides it dosen't make much business sense to use a OR search.
- SB
[ August 07, 2003: Message edited by: S Bala ]
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi S,
If look at commercial applications we will never see such a DB interface
I first provided also only AND search, but after review of specification I realized that that want also "OR" search. The worst thing is that it is "MUST" requirement. So failing to satisfy this requirement means failing the assignement.
I tried to interpret it your way. I asked my wife (she is an IT consultant and it her primary job to understand client specification).
Bad news: She said it is very clear: a user should specifiy which search he preffers: all, and , or.
It is up whether to make jcombobox or jlist instead of jtextfield to enter
hotel/location as a search criteria, but it has nothing to do with type of search.
May be I tell you stupid things, but that is how understand the specification.
Vlad
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
The specification is VERY CLEAR on this issue!
No, it isn't. The specification for the find() method is clear enough, but that's separate. The GUI spec is more flexible:
"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."
This has two definite consequences:
(1) User must be able to search for all records.
(2) User must be able to search for records where the name AND location match.
The OR is more flexible. It could mean
(3a) User must be able to search for records where the name matches, or search for records where the location matches.
Or
(3b) User must be able to search for records where the name matches or the location matches.
Or
(3c) Both 3a and 3b.
All these are legitimate interpretations; the spec simply does not provide enough info to distinguish which is really meant. Now the way the find() method is written we are sort fo encouraged towards 3a. However find() isn't exactly compatible with the search requirements anyway. because of the difference between 'starts with" and "exact match". So we need a adapter anyway to get the results we really need from find(); once we put in the adapter, it can call find() twice to achieve 3b (and 3c). And given the fact that it's difficult to get better info from Sun, and if we fail it's hard to get a grade change, perhaps the safest solution is to assume (3c). That still doesn't mean 3b/3c are definite - it just means it's safest to implement them anyway.
However, this goes make our GUI interface a little more complex looking. And in fact, 3b / 3c never explicitly say that the results have to be viewable as a single search. A user could simply do a search for all matching names, then another search for matching locations - there, they've seached for all records with a matching name or matching location. I honestly think that's a perfectly legitimate interpretation of what they said. But I don't know if it's really what they meant.


"I'm not back." - Bill Harding, Twister
S Bala
Ranch Hand

Joined: Jul 15, 2003
Posts: 49
I really hate the way Sun is putting fuzzy requirements especially in the "must do" clauses.
It dosen't make any sense why an user would do a inclusive "or" search rather than an exclusive "or" search.
Looks like the adaptor should call the find method, then loop through results to see if it is an exact match. We need to do this for both location and name.
hmmm...
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Jim,
As I said, I decided to make search as (3b). It works perfect, but the code is ugly:
1 search by hotel and
put all found record numbers by hotel record numbers in Set
2 search by location and
put all found record numbers by location record numbers in Set
3 read all records for found record numbers
4 Transfer all record numbers from Set to array
5 filter records since search criteria
in client differs from the one on the server
It means that I make two separate invokation of int[] find(String[] criteria);
If , in future, use wants to search by 6 fields , I would have to make 6 separate find calls;
Another alternative (as S says):
1) first search for all record numbers
2) read all records
3) use own algorytm (on the client or in business layer (adapter class)) to find
appropriate records
which also ugly.

I didn't want to discuss whether it is reasonable to make (3c) search. We should do it not to play with MUST requirement.
My question is whether you have any other ideas how we could implement this search in more elegant way.
Many thanx,
Vlad
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
If , in future, use wants to search by 6 fields , I would have to make 6 separate find calls;
Yeah, it's ugly. The thing is, the find() method isn't very well-suited to most future enhancements I can imagine. E.g. how do you specify case-insensitive? How would you search for something containing a phrase rather than starting with it? How could the user input an arbitrary regex? For numeric values, how would you search for a range e.g. 990-110? Basically, find() is OK for the minimum search requirements we have been given (though it's already pretty ugly for 3B); but it's very impractical for other real-world enhancements. If I had to do other enhancements, I would convince the customer to add a new find(SearchCriteria) class to the interface, where SearchCriteria is:

This would be flexible enough to allow lots of different types of searches. Without that - well, I'm not really interested in worrying about how to use find(String[]) for other enhancements, unless someone's paying me. It's a crappy interface.
The ugliness of the 3B code is another argument for using the 3A interpretation, IMO. It's already easy enough to find by name, then find by location. Who relly needs to be able to find by (name or location)?
I didn't want to discuss whether it is reasonable to make (3c) search.
3C wasn't intended to represent a single search, rather, it was supposed to indicate that the user could choose either 3A or 3B. I think that since 3A is easy to do, anyone who does 3B will do both anyway, so they're really doing 3C. But to me they are three separate and distinct possibilities - implement just 3A, implement just 3B, or implement both 3A and 3B.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Just my 2 cents worth ...
The signature of the find method Sun provided seems to work for options 1, 2, and 3a. One method does everything.
However implementing 3b and/or 3c would require another method, one that is not detailed in Sun's interface. Which kind of defeats the purpose of the interface.
So my gut feeling is to avoid making the project more complex than it has to be, and only go for options 1, 2, and 3a.
The equivalant description in the old project was: "The user should be able to select the origin and destination of flights, and the display should update to show only flights that satisfy those criteria. The user must be able to describe enter the string value "any" for the origin, destination, or both, so as to implement a wildcard-like feature."
So option 3a would be keeping the level of work the same as the old project. The change of wording could be to try and stop people from forcing the user to enter something in every possible search field.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Vlad Rabkin
Ranch Hand

Joined: Jul 07, 2003
Posts: 555
Hi Andrew,
Tx for joining the topic!
The specification of FlightByNight looks to be different. It does not require "Or" search (3b).
Andrew, Jim, S,
It looks like your suggesting is to avoid doing "OR" searching by trying to
turn the interpretation of the URLyBird requirement, which is easer to implement, which extremely dangerous game.
Oeah...

Vlad
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Maybe the spec is written in real English and we're thinking in logical English, which can be the problem with many of us including myself.
This sits easy with me as it involves the least amount of work.
Tony
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Additionally I don't understand why the interface doesn't have a method that matches exactly, snd not this startswith thing.
THough I supose you could just pad out all the fields and use the startsWith match to get the equals result.
Tony
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435

Excuse me for being so slow, it's just clicked.
If we use a JBox the user can only select the full value for each field,
so findByCritea is OK.
In our adaptor class for data I can imagine we could use findByCritea with the critea set to all nulls, to get the various possible fields for location and name. Then use findByCritea to search the database with the users choice.
Tony
Bob Reeves
Ranch Hand

Joined: May 01, 2003
Posts: 64
Hi All:
My assignment was the URLyBird application, and I can relate how my submission was scored. I interpreted
"to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user"
and "the search mechanism should be flexible..."

to mean two two specific search types and received Sun's OK:
1. Specify no criteria and get the "all records search".
2. Specify both name & location and get the "AND" search, or
search just name or location (i.e., other field is blank in query) and get
the "OR" case.
For the "flexible" search, I just provided an implementation that didn't prohibit using all fields in the FindByCriteria method. My implementation used nulls for "TBD" fields, but the comparison took place on all fields.
I also provided an "Exact" search where only records that matched identically were returned; i.e., fred does not match freddy.
The important thing, I think, is to fully document your interpretation.
Tx
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Bob
Thanks for that - since you got full marks for Data Store, it may validate our thinking.
Regards, Andrew
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11404
    
  81

Hi Vlad,
The specification of FlightByNight looks to be different. It does not require "Or" search (3b).

Agreed. My comment was more that without the 3b option you would be doing an equivalant amount of work as the old assignment. With the 3b option, you would be doing significantly more. Given how close the three assignments are otherwise, I would be surprised if Sun were giving you so much more.
It looks like your suggesting is to avoid doing "OR" searching by trying to turn the interpretation of the URLyBird requirement, which is easer to implement, which extremely dangerous game.

Personally I do not feel that I am changing the interpretation. My reading is that the "or" refers to only specifying data in one or the other field. The way I am reading it, you have to search on:
  • all records,
  • or for records where the name and location fields exactly match values specified by the user
  • or for records where the name fields exactly match values specified by the user
  • or for records where the location fields exactly match values specified by the user


  • To me, saying and/or is just a more concise way of combining the last three options.
    As indicated previously, I feel that my interpretation is supported by the method signature and by the amount of work involved in the FBNS assignment.
    Regards, Andrew
    Jim Yingst
    Wanderer
    Sheriff

    Joined: Jan 30, 2000
    Posts: 18671
    Miscellaneous responses...
    [Andrew]: However implementing 3b and/or 3c would require another method, one that is not detailed in Sun's interface. Which kind of defeats the purpose of the interface.
    Well to be fair, 3b and 3c don't require a new method. We can use the existing find(), by calling it twice. And removing duplicates from the results, and probably sorting by recNo. (TreeSet would do nicely.) But it's ugly, and inefficient, and clearly isn't a very good fit for the find() method - we'd prefer a different method. But it's possible to use this one.
    Still, I agree with the sentiment. I think I'll stick with my original 1/2/3a solution. Especially as Bob has kindly offered additional support for that.
    [Vlad]: It looks like your suggesting is to avoid doing "OR" searching by trying to turn the interpretation of the URLyBird requirement, which is easer to implement, which extremely dangerous game.
    Like Andrew, I don't think we're "turning" the interpretation. There are two (or three) perfectly legitimate interpretations for the requirement given; we're favoring the one that's simpler. To be honest, this was also the interpretation that first occurred to me when I read the spec. So it's not that I'm trying to find a simpler interpretation; it kind of jumped out at me.
    [Tony]: Additionally I don't understand why the interface doesn't have a method that matches exactly, snd not this startswith thing.
    I think it's another example of Sun simulating semi-stupid customers, to give us more of a challenge. Or to be more charitable... maybe there's a legacy system (which they neglected to tell us about) which uses the DB interface, including the crappy find() method. That find() method might have been an exact match for the reuirements of some other system; now we've got slightly different requirements, and we're expected to adapt the legacy interface to the new situation. This sort of thing happens all the time in the real world, unfortunately. Just gotta deal with it.
    [Tony]: If we use a JBox the user can only select the full value for each field, so findByCritea is OK.
    Mmmm... but don't you also allow the user to type in their own text to search for? I think that really needs to be an option. What if the user wants to search for something that was just entered in the DB, after the JComboBox options were initialized? I suppose you could allow a manual refresh of the box options. (Or it could be done automatically, but I think that would generate a lot of unnecessary work for the server and network.) And what if the DB grows huge and there are thousands of unique values to choose from? It may not be practical to list them all in the JComboBox, or even if they're listed, the user may not want to try to search through them all.
    Thanks, everyone, for the interesting opinions...
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi guys,
    Andrew, Jim - you were right!
    Special thanx to Bob!
    Ok, I have ,like always, made all things too complicated ....
    Tx!
    Tony Collins
    Ranch Hand

    Joined: Jul 03, 2003
    Posts: 435
    [Tony]: If we use a JBox the user can only select the full value for each field, so findByCritea is OK.
    Mmmm... but don't you also allow the user to type in their own text to search for? I think that really needs to be an option. What if the user wants to search for something that was just entered in the DB, after the JComboBox options were initialized? I suppose you could allow a manual refresh of the box options. (Or it could be done automatically, but I think that would generate a lot of unnecessary work for the server and network.) And what if the DB grows huge and there are thousands of unique values to choose from? It may not be practical to list them all in the JComboBox, or even if they're listed, the user may not want to try to search through them all.

    Yeah but in this release we can't create new records.

    Tony
    Dirk Band
    Greenhorn

    Joined: Jun 16, 2003
    Posts: 8
    Hello everybody,
    my assignment says:
    // Returns an array of record numbers that match the specified
    // criteria. Field n in the database file is described by
    // criteria[n]. A null value in criteria[n] matches any field
    // value. A non-null value in criteria[n] matches any field
    // value that begins with criteria[n]. (For example, "Fred"
    // matches "Fred" or "Freddy".)
    public long[] findByCriteria(String[] criteria);
    I understand that criteria[0] is the first database field. In my case it's name.
    criteria[1] is second database field (location). and so on.
    Example: findByCriteria({"Fred","Dallas","80$","",""})
    Am I rigth?
    Vlad Rabkin
    Ranch Hand

    Joined: Jul 07, 2003
    Posts: 555
    Hi Dirk,
    Yes.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: URLBird find by Hotel or Name
     
    Similar Threads
    Search
    URLyBird findByCriteria
    find method in B&S
    a question about requirement, findByCriteria
    Do we need to filter the search result data?