• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Conflicting search requirements (URLyBird 1.1.3)

 
Josh Allen
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The UI section says:

It must allow the user to search ... for records where ... fields exactly match values specified by user.

The Server Interface section says:

How am I to reconcile these conflicting requirements?
 
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 Josh,

In my opinion, there is no conflict .

You have two separate programs to write. One is a data server, which has it's own set of requirements. The other is a GUI interface, which also has it's own set of requirements. Both sets of requirements need to be met.

Perhaps it is easier to think of this in terms of two separate companies writing code: one doing the server code, and one doing the client code.

When you are working for the company writing the server code, you must follow the requirements for the server code.

When you are working for the company writing the client code, you must follow the requirements for the client code. At the same time, you must accept the APIs and data output provided to you by the company writing the server code.

As for how you handle this: perhaps an additional filter at the client side?

Regards, Andrew
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great work! That completely slipped past me (of course I've read the document only a few times and have not started coding yet). I am wary of the solution of putting an additional filter on the client side, the only reason being it seems to be a convoluted solution to me. I think data processing and filtering should be done at the server side as much as possible...

Have any of the veterans noticed this? It seems to me this is an honest mistake by Sun. One way to interpret this would be that it is merely a problem of semantics and the server-side documentation is what the true intent is. Here "exact" means matching exactly the input/output expectations of the user?

In any case, this would be a great design decisions topic...the "must" part of the client side requirements is a little bit scary though...Have you thought of posing the question to Sun? I would be interested to see what their response is...
[ February 01, 2005: Message edited by: Reza Rahman ]
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In some cases you may be correct, in this particular case the requirements clearly state that the server must behave in one way and the client in another.

Think of it as you purchasing a database server which doesn't understand a where clause properly and always interprets it as a like.
When you query that database with "fred" as the name of the person you're looking for, to your surprise you're also getting "freddy kruger", not just "fred flintstone" (first name and surname are 2 separate fields of course, you searched only on the first name).

You will now need to include functionality in the client to postprocess the data returned by the server to filter out the records you aren't interested in.

I'd personally create that filter in such a way that I can easily turn it off at runtime, as requirements in the real world do change.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think there is any mistake by Sun. The Client should allow for searches where the criteria exactly matches the data in the record. It does not care how the search is conducted by the Server.
Now when the assesor is grading your assignment, they will not necessarily use the provided Client to test your server methods, so therefore, your requirement states that the find() method must search on data that starts with the provided criteria.
There is no conflicting requirements, just like while your Client won't provide a way to create or delete a record, your Server will still have these methods implemented.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd still be interested in hearing from someone who has actually submitted their assignment and dealt with the same problem rather than assuming everything is fine and making an unduly convoluted solution if this is just a problem while publishing the specs.

I wouldn't feel too uncomfortable in asking Sun if this is indeed an intentional problem to work through. If it is, I agree, the "Thick Client" solution is unavoidable here even if it is a little awkward.
[ February 02, 2005: Message edited by: Reza Rahman ]
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can pose the question to Sun if it would make you feel more secure, but it wouldn't surprise me if you only received the answer that "This is not a mistake." After all, Sun stressed the important of working through problems yourself and then justifying your decision in your documentation.
In general, you should not ask your question; rather you should consider the options available and make a decision about how to address the problem yourself. This decision-making process is part of the marking scheme, and as such it is crucially important that you provide documentation of your choice. Be sure to describe the options you considered, the perceived benefits and weaknesses of each, and why you chose the solution you did.
Personally, I don't see this as a conflict in the requirements either. I agree with Andrew's post earlier in this thread.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll wait a bit to see if there is some further input by an exam veteran who dealt with this problem successfully. If not, I'll post the question to Sun and let you guys know what happens (provided it isn't a non-disclosure issue). I don't think simply asking if this is a typo should be an issue, it just might save people from aggravation in the future...

The problem is that the bottom section of your quotation also mentions the fact that the decisions we take must conform to all the "must" specs. In my judgement I see two "musts" colliding here...I'm also really finding it hard to believe the problem would force us into a thick-client solution.
[ February 02, 2005: Message edited by: Reza Rahman ]
 
dennis du
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am some confusing by this.

But for now ,I changed my client UI. I set the JComboBox to non editible.
So user can search exactly the records.

But on server part, I fulfilled this with startwith .

I think this should be ok.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dennis,

I think it depends on how lenient the evaluators are. If they take it easy and there are no name/location records in the datbase that could cause you to retrieve records the user was not expecting (e.g. "Freddy" for "Fred"), you'll be just fine. If there are or if the evaluator is particularly picky while looking through code, you might have an issue...Hope this helps.

Reza
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reza,
I still don't think this is a typo, nor is it a conflict. You are looking at the application as a whole, instead of looking at the requirements of each part separately. I also fail to see why the assignment is forcing you to implement a thick client. The thin vs thick client issue has been discussed several times on this forum, as has this issue. Here are some links to other threads dealing with the searching issue. (There were actually a lot more, but I didn't have the time or patience to copy them all )
Link #1
Link #2
Link #3
Link #4
Link #5
If you are still unsure, by all means email Sun and post the answer here. Otherwise, be sure to document your decision in the choices.txt file. Good luck!
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul:

Thanks, the links are great! I'll check them out. I'm trying to look through all the posts myself and raising issues I think are troublesome!! In either case, I'll keep posting what I decide and possibly Sun's response. I'll do it as promptly as I can so others can benefit too...

Reza
 
Dieskun Koper
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also did not see it as a conflict. The interface has several methods that our client does not need: create, delete, and this find method. I used NOPs for the methods I did not need, and added a find method for the purpose I needed. I got 40/40 for Data store.

In 'real life' we usually do not have access to the database code so we can't add or change any DB methods, so as others suggested an extra filter would be required.
In this case, we have to write the DB code too so we might as well customize it for our needs.

Regards,
Dies
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dieskun:

Great! This is the kind of response I was looking for! Did you extend the interface to add your new method? Without going into too much detail, what did you do about differentiating the naming? Or did you use some form of polimorphism to deal with the two flavors of search (certainly sounds that way)? One solution could be:

1. Create the search method specified in the interface.
2. Create a polimorphic version that utilized the output from the first method but employs additional filtering (maybe a simple on/off flag?).
3. Extend the interface to add this additional method.

In either case given the constraints I would say this is much better/cleaner than adding additional data handling logic at arbitrary layers rather than keeping it cetralized at the "database" layer...

Your input is much appreciated.

Reza
[ February 02, 2005: Message edited by: Reza Rahman ]
 
Josh Allen
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for help. I really do think that it's an odd conflict in the requirements, even if technically a solution can be worked out to fufill both. It's just that to do so you would have to essentially create two search functions, and I question if this was actually an intent of the assignment.

To be safe I'm going to implement a secondary function in the client that goes through the records returned by the server and filter out ones that don't exactly match.
 
Anton Golovin
Ranch Hand
Posts: 527
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I asked the same question you did, and got the same answer, and implemented it. One requirement deals with the data layer, and the other with the presentation layer. So the assessor will look for code in the Data class which implements partial search and code in the client (or business code on your server) which implements the complete search.

It is also helpful to do a complete search because there is a possibility you could get wrong records with the partial search. Consider the following:

1) You find() a bunch of matching records.
2) You read() each record.

But multi-threading, that record could have been changed between the find() and read(), and even though it matched at the time of the find(), it does not match at the time of the read(). How to catch it? With the conveniently required complete search. So come to think of it, the requirements would be incomplete were they not dual this way.
[ February 02, 2005: Message edited by: Anton Golovin ]
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

I don't have a problem with the server side "find" and client side "search" requirements. However, what's also added to the mix is this line in my spec - B&S 2.3.3:
They take requests from home owners for a type of service, and offer the homeowner one or more contractors that can provide the required services.


To me this seems like a requirement that the client should be able to also search for a service as well. Therefore, I'm wondering if it would be ok to implement a strict search feature for names and locations, but also a weak search feature for services, names and locations? Do you think this would give credit under the general considerations criteria or would be seen as outside the requirements scope?

Cheers.
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Matt Garner:
To me this seems like a requirement that the client should be able to also search for a service as well. Therefore, I'm wondering if it would be ok to implement a strict search feature for names and locations, but also a weak search feature for services, names and locations? Do you think this would give credit under the general considerations criteria or would be seen as outside the requirements scope?


Hi Matt,

I thought the same thing. I added a text field for the services field to my dialog and also an option to switch between an exact and a partial match.
This does not violate the original musts, but merely adds some extra functionality and I documented as such in my choices.txt.

I submitted only two days ago, so I can tell you in a few weeks if my assessor liked my ideas

Frans.
 
Eric Chang
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reza, you don't have to do any of that stuff you mentioned. You will still only have a single find method, implemented the way it states in the comment (ie: using startswith). The place where you restrict the client to search on the full value of a certain field is at the client.
Now, you can keep in mind that the requirement states that the user must be able to search on a field using the exact match, which means that the user can ALSO search on a field using a partial match (again, with startswith). As it was not stated that the user must ONLY be able to search with an exact match, you can search on an exact match and partial match.
Some people have decided to implement the client search GUI with JComboBoxes, which are populated with the values retrieved from the database, thereby forcing the user to search on exact matches. However, some people have also decided to use regular JTextFields to allow searching on partial matches as well. Either method of searching is acceptable from what I've read.
Just remember that there is no conflicting requirements. Just look at it this way. You provide "extra" functionality in your server in provided the ability to partially match a value...it's up to the client to decide whether or not it wants to be able to use that functionality or not. As far as the client is concerned, it MUST be able to search on an exact match, but it can also search on partial matches if you decide to implement it that way.
 
Colin Yates
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JCombo boxes (in themselves) do not satisfy the "must be exact" because the records in the database can have changed since the combo boxes were constructed.

clientA: populate combo with distinct(name)s {nameA, nameB, nameC}
clientB: modify nameA to nameAAA
clientA: find all nameA

the 3rd operation will return all records with nameA <strong>and nameAAA</strong>

I resolved this by having the client do the following:

- find all matches
- for each matched recordId
- read the record from the server
- if it has been deleted, continue
- if it is no longer an exact match continue
- great, it is still a valid match

Also, remember, you need to refresh those lists of combo boxes regulary. I do it evertime the user clicks a search
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Colin Yates:
Also, remember, you need to refresh those lists of combo boxes regulary. I do it evertime the user clicks a search


Hi Colin,

I am not so sure that is such a great idea. It probably works like a dream on your home computer with a single client running. Now imagine that the database is very large (thousands of records); imagine there are many clients spread out all over the world; imagine that the server is connected to the internet through a 14k4 modem...

Would you still want to read all your records on every search?

Frans.
[ March 01, 2005: Message edited by: Frans Janssen ]
 
Colin Yates
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hiya.

First off, we are not righting a large, multi-user app, we are writing a solution for an abitrary, and quite unrealistic spec.

Second, I don't read all the records, I ask the server to give me a String[] of all the unique names, and another String[] of all the unique locations. To rephrase, the server compiles a *cached internal to the server* list of unique names/locations and sends the list to the client in one chunk.

You absolutely do need to do this *at some point* because someone else could have modified the database so your local list of unique names is now out of date. Rather than leave that up to the user to decide when to do it, I decided to do it for them.

To be honest, my commercial mind just cannot imagine users from around the world using this app
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Colin Yates:
To be honest, my commercial mind just cannot imagine users from around the world using this app


To be honest too, I don't think anything we will come up with will have much added value to something one could make with a simple Excel sheet and a phone

But seriously, I think searching using free-format strings that the user can enter seems much more flexible to me. It is the way you search in most common desktop applications (e.g. MS Access, Google (imagine Google provided searching using combo boxes containing all their keywords!) etc.). Free-format searching will liberate you from the need to update a collection of key words.

And personally I don't like having to select items from combo boxes if they contain more than five items. For example, don't you hate it when a website makes you select your country from a combo box containing all countries in the world?

Frans.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic