• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S What Are You Guys Passing Into Your findByCriteria For criteria[2] Thru [5]?

 
Bob Nedwor
hangman
Ranch Hand
Posts: 215
Eclipse IDE Oracle Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you pass in NULL, the findByCriteria method will see that as a valid match, based their requirements:

// 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);

However, the UI requirement states:
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.

I think Sun is messing with us. I am not going to use findByCriteria. Even though I put code into the implemented version of the method to make it work the way they've asked, it is useless.

In order to meet the UI requirement, I am just going use the readRecord() method.

What do you guys think? Thanks for your comments.
 
Kai Witte
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

finding what you just found certainly is part of the test. I like this little dissonance, because "such things" are very typical in real world projects.

Your conclusion that you have to filter the search results, typically on an other layer, is correct. What does your readRecord do? Take a record number and return a String[] (single record)? How would that help in this case? I don't see where you would get valid record numbers to pass to readRecord, other than from the find method.

Kai
 
Yupp Cook
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bob, hi Kai

Of course Sun is messing with us but that's part of the deal. They wanna see our ability to handle those dissonances. Indeed that's what developing is all about: solving problems.

We should use find as far as possible not re-inventing the wheel. The dissonances coming along with the use of find can be straightened up in a different layer.

Implementing the All-search and And-search can easily be done with find.
Implementing the OR search can be solved by calling find twice consecutively. The two results simply have to be logically OR-combined.

Yupp
 
Bob Nedwor
hangman
Ranch Hand
Posts: 215
Eclipse IDE Oracle Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Kai and Yupp. Yes, readRecord does exactly that. My Data.java will know what all the valid record numbers are. I will loop though all of the record numbers and find the subcontractors who match (based on the name, location, both or neither) and whose getOwner() = " ".

You both have a customized getOwner() method, right?

I don't have a find() method - only findByCriteria(). But I guess I could pretty easily build one based on the algorythm I described above, right? Thanks for any further comments.
 
Kai Witte
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

I have done my SCJD a long time ago, with an old B & S version. The methods of the interface appear to be similar, but with different names.

I recommend to use only the methods from the provided interface. In this case, use the find method as good as it works (with the "starts with ..." filter) and filter the results again on an other layer. Many have done it this way and have gotten full score for all associated sections, including me (96 %, 384 / 400 total).

If that is not explicitly disallowed, it seems to be a sane option to make an additional interface for the find methods you want which extends the provided interface. Because of the "must implement ..." clause and possible far fetched interpretations of it, it might be best to have Data implements DBMain, ExtendedDBMain, although that would usually be silly if ExtendedDBMain extends DBMain already. If you choose the way of the extended interface for the data access, document it heavily in your choices file.

Kai
 
Petter Andersson
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Here is another way of getting around the "starts with" and "exact match" inconsistencies:

When doing the search from the UI, pad the search criteria with spaces. At least in my database, a loaction of "Smallville" is stored as "Smallville" followed by 54 spaces (to reach the field size of 64).

Search for Smallville and 54 spaces instead of Smallville. This will give an "exact match" search using the supplied interface.
 
Eiji Seki
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Strange, I did not notice anything wrong with the findByCriteria method.

I am just implementing the data layer as the interface says, and all the rest is going to be done in the business layer. I'm just thinking that it is really a data server with no knowledge of the business information, so all the logical stuff must be done somewhere else.

About filtering records with owner, it is a good point. Since I do not like the idea of hiding them or just showing them, I guess a "show free only" flag should do it.

Since my data interface explictly states that the findByCriteria should look for exact matches, that's what I will do. But the blank/null problem is still there. I raised this subject in another thread, but I can say I am right-trimming the values, since always appending blank spaces to the criteria will not always work: just imagine if somehow a value is entered the correct way (null terminated). WOW! Although it is most correct, your criteria will not find it.
 
Petter Andersson
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, that's right, I missed the part in the spec about the null terminated string values. Thanks for bringing it to my attention.

This means, like you point out, that my approach to searches with padded criteria does not work very well. Back to the drawing board...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic