UrlyBird 1.2.1 findByCriteria(String[] criteria) and searching algorithm doubts

[Krzysiek Hycnar]

Hi,

In general the whole post is about boundary conditions

Firstly, I'm in little doubt if my implementation of findByCriteria is correct. According to the specification:

//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".)

What if criteria[n] = "" - that means an empty string?? Is it supposed to match anything (like a null value), or literally an empty string in the column to which the n index corresponds??

I implemented it in a way that it matches anything (just following recursively the path: if "Fred" matches both "Fred" or "Freddy", than "F" matches anything that starts with "F", so "" matches anything).

What comes next is the searching algorithm.

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."

What does an empty field in the search criteria mean here, anything or literally an empty string??

If an empty field means anything, the search with the following criteria:

name = "Castle" AND location = "" will return only the records that have "Castle" in the name column, similarly name = "Castle" OR location = "" will return the whole database contents.

On the other hand, if we assume that an empty field means literally an empty field in the database, the:

name = "Castle" AND location = "" will return records that have "Castle" in the "Name" column, and "" (an empty string) in the "Location" column - in case of the provided database file the result set will be empty.
The name = "Castle" OR location = "" in that case will return only the records that have "Castle" in the name column - since in the provided database file there're no entries with an empty location field.


Which of the above is a better approach?? Guess this is a good thing to place in the choices.txt

Take Care
Krzysiek

PS. BTW, Please be sincere, and tell me if I'm getting paranoid - maybe it's not too late
[ December 01, 2005: Message edited by: Krzysiek Hycnar ]

[Lara McCarver]

The way I did it is,

In the find() method in data, "" means anything.

For the find method used by the client (not the same one, obviously), "" means just "" and nothing except "".

If the user didn't fill in a field (like Location) in the search criteria, I put in "null" for that field. For the method used by the client, null matches anything.

I agree that it's worth mentioning in the issues.txt file. But my issues.txt is getting long. Maybe I should cut down the design commentary... I am not certain whether you are even supposed to include design documentation in issues.txt, but it is helpful in understanding the program.

Lara

[Robert Aragon]

Example: All fields are null except for field[4] = "150".

Your findByCriteria method then returns an array of indices whose corresponding records match the 4th field. You would NOT want to be obligated to match EVERY field. Users usually look based on the match of just 1 field.

It's all good.

[Thomas Kruse]

Well I am not so sure about it (UrlYBird 1.3.3), since it reads in my specs (Userinterface)
"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". (Read again: It says it MUST)
I changed my gui, so I can search for an exact match or (as stated in the interface) for a substring match. But I did not implement the boolean AND (yet).
I guess the specs are not really clear about this.

[Arun G Rao]

My 2 cents on this issue. Here is what I thought would be the most simplistic implementation. Please let me know if this makes sense.

The AND/OR is meant from a usability perspective. The user may enter both (interpreting this as AND) or either one of them (interpreting this as OR) or nothing (Search All). And we are told what are permissible search fields.

Instead of searching for the entire record for patterns, I was thinking of looking only into those two fields and use the values provided by the user and interpret the AND/OR condition.

IF we were to move to a RDBMS, this is exactly what we do too - Search by specific columns.

Arun