aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes name and/or location search Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "name and/or location search" Watch "name and/or location search" New topic
Author

name and/or location search

Zafer Abu saeed
Ranch Hand

Joined: Mar 28, 2004
Posts: 40
Hello all,
Search requirements:

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.

As English is not my native language, do you understand name and/or location as allowing search for:
Exact Name and ANY Location
ANY Name and Exact Location
Exact Name and Exact Location
or as:
Exact Name and ANY Location
ANY Name and Exact Location
Exact Name and Exact Location
Exact Name or Exact Location
(GUI-wise, do this implies that an operator (i.e: AND / OR ) should be selected when performing search?)


Thanks,<br /> Zafer<br /> SCJP, SCWCD
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Hi Zafer,
I have implemented 4 searching methods:
Exact Name AND Exact Location
Exact Name OR Exact Location
Not Exact Name AND Not Exact Location
Not Exact Name OR Not Exact Location
The 1st 2 cases are what I get from the insturctions, and the latter 2 cases are added by myself. I think you just need to implement the 1st 2.
About the GUI, I have 2 textfields (name and location), 1 selection box (AND/OR) and 2 radio buttons (Exact or Not Exact).
I added the latter 2 just becos exact match does make sense, if everytime I need to type the whole name, or address, if I have some typos (maybe I even forget the spelling), I cannot locate the hotel! Thus, I added an extra feature. But I dont think it is needed in fact.
Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
I believe this depends on the particular assignment. I'm working on URLyBird 1.2.1 and I've also got this and/or statement in my specs. However, the DBAccess interface provided by Sun contains this piece of code:

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

So, exact/partial matching is not the question. Method hint: String.startsWith().
I'm not so sure about the and/or though. findByCriteria() has got no parameter to choose between the two search modes. Shall we just implement either and document it or...?
Regards,
Marcel
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Zafer and Marcel,
Searching on name and/or location ... one of my favorite past topics!
It's too late for me to enter in discussion tonight about it, but this thread may help you.
Regards,
Phil.
[ April 27, 2004: Message edited by: Philippe Maquet ]
Denis Spirin
Ranch Hand

Joined: Mar 22, 2004
Posts: 72
Interesting question. I think "and/or" should be understood as follows:
1. exact name and exact location
or
2. exact name, any location
or
3. exact location, any name
Just do not look at it from programmers point of view. We dont write search engine; this is booking system and I personally see no sence in implementing feature "look for exact location match OR exact name match". Can you imagine such situation:
client calls CSR and asks: Hey, book me a room in Emerald City or hotel named Palace in any other town on Jun 9 ?
Well, that sounds odd for me.


Regards<br /> <br />Ph.D.<br />SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJD 2
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Denis,
Why do you come up with "exact search" again? I believe Sun's comment in the DBAccess interface is very clear. IMO partial matching (starting at beginning of criteria i.e. as in startsWith()) should do.
As for the interpretation of and/or I would say Phil hit the nail on its head (see the other thread he mentioned):
The "and/or" in your instructions can be translated in : search on name, or search on location , or search on name and location.

So, if both criterias have been supplied it's an AND search, otherwise the case is clear anyway.
Regards,
Marcel
Denis Spirin
Ranch Hand

Joined: Mar 22, 2004
Posts: 72
Marcel,
we should implement find() method as it was proposed by Sun (i.e startsWith()) but
it is clearly said that
It must allow the user to search the data for all records, or for records where the name and/or location fields exaclty match values specified by the user.

This means that implementation of method is different than it is presented to user. Anyway I cant understand what the problem is.
Regards,
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Denis,
Anyway I cant understand what the problem is.

I'm a little uncertain about your use of "exact name/location". Maybe an example will explain what I mean:
  • "" (or null) for hotel and "" (or null) for location will find all records
  • "b" for hotel and "" for location will find all rooms in hotels that start with b such as Bilton, Bed & Breakfast, etc but not Cab Inn
  • "" for hotel and "b" for location will find all rooms in hotels that are located in a b city such as Bollywood, Boston, etc. but not Alberta
  • "b" for hotel and "b" for location will find a combination of the above two items such as Bilton in Bollywood
  • Perhaps we're talking about the same thing in different words?
    Regards,
    Marcel
    Denis Spirin
    Ranch Hand

    Joined: Mar 22, 2004
    Posts: 72
    Marcel,
    what I mean is that
    1. "" for name and "" for location gives all records
    2. "" for name and "Calgary" for location gives all hotels in Calgary
    3. "Hilton" for name and "" for location gives all Hiltons anywhere
    4. "Hilton" for name and "Calgary" for location gives all Hiltons in Calgary
    I see here 2 problems
    1. It is not clear what "name and/or location" means. Does it mean that we can search for
    "exact name OR exact location" (say "Hilton" OR "Calgary" will give all Hiltons and all hotels in Calgary as well) ? I guess the answer is : it is up to us. If Sun wanted us to implement AND/OR
    search, it would have been another MUST in instructions. So you may implement it or you may not.
    2. It is written that
    It must allow the user to search the data for all records, or for records where the name and/or location fields exaclty match values specified by the user

    On the other hand, in DBMain interface we find

    // A non-null value in criteria[n] matches any field
    // value that begins with criteria[n]. (For example, "Fred"
    // matches "Fred" or "Freddy".)

    We MUST provide search feature for exact name and/or location, but in find() we have to use startWith().
    I guess the only way to do this is to implement find() as it is proposed in instructions, and give user lists of possible choices for names and locations (say, via ComboBoxes). Thus, method find is implemented as proposed, and user gets only exact matches (although we used startWith).
    Regards
    Satish Avadhanam
    Ranch Hand

    Joined: Aug 12, 2003
    Posts: 697
    Originally posted by Denis Spirin:
    Marcel,
    I guess the only way to do this is to implement find() as it is proposed in instructions, and give user lists of possible choices for names and locations (say, via ComboBoxes). Thus, method find is implemented as proposed, and user gets only exact matches (although we used startWith).
    Regards

    My 2 cents. You can implement your own find methods and use them for EXACT if you want.
    Ben Zung
    Ranch Hand

    Joined: Mar 25, 2004
    Posts: 109
    Thank you Satish. I was just wondering why not do what you said. It is perfectly fine, I think, to write our own method to do finding. I got exactly the same requirements with the contractor assignment and what I am doing should sound reseanable. There is no where in the specs say:
    "You MUST not perform search use you own method instead of my ambiguous,
    not well-written, sometimes nonsense ones".
    So it should be safe.
    1. I provide the CSRs every field for search
    name: (customer question -- Will contractor xxx be able to help me?)
    location: (customer question -- Is there a contractor near to my home?)
    specialties: (customer question -- Who can do the tuck pointing for me?)
    size: this is the only one that does not make sense to be a searchable
    index. Nonthenes I present it to the CSR anyway. It is not worth
    the hassle to just pick this only one out. I stated it in my
    choices.txt. Unless a customer says something like this: I prefer
    a bigger company. Because they may have done a lot of good work
    so they have so many contractors signed on ... (ok, I stop)
    rate: customer question -- I can pay too much for the job, find me
    one cheaper
    owner: customer question: -- (very angry) Yes, I booked it yesterday.
    My customer ID? it is xxxxxxxx. check it out and let me know, Ok?
    2. by default the search will be a startswith:
    if one term is given, search that index use startswith
    if two terms are given, seach each index use startswith
    ...
    3. a toggle button gives the user to choose to do a exact match
    if one term is enterred, as long as that index is a match
    (equalsignorecase) the whole record is a match
    if two terms are enterred, exactly matched on that tow indexes is a
    match record.
    ...
    4. I ignore the case in both case. as this makes sense in real word.
    this may conflict with the example given in the specs: For example,
    "Fred" matches "Fred" or "Freddy". But I bet if you don't ignore
    the case, some grader might thing that you are not being realistic
    and become more critical on other parts. Who knows. Just me imagination
    Finally, personally I think the idea of bringing up all record if none of
    the search terms is given is not a very good idea. If you do a search on
    google with nothing, will google give you millions of millions of pages
    they are warehousing?
    Anyway, just my 2 cents (in Japanese Yen)
    bing
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11460
        
      94

    Hi Bing,
    The only concern I would have with your approach is that you are adding a lot of functionality that I believe is not required.
    You probably have a line in your instructions stating that:

    Your project must conform to this specification. Features that deviate from specification will not receive full credit. You will not receive extra credit points for work beyond the requirements of the specification.

    So if your submission was identical to mine except that you had the extra search functionality, then one of two things will happen:
  • Best case: we get the same score
  • or I could get a better score than you. You could loose points for having done something wrong in your additional code, or you could loose points if the examiner felt that you were deviating from the specification.


  • There is no chance that you would get a better score than me for the additional work.
    To be honest, I like the additional search functionality you suggested. If this were the real world, and I had contracted this job out to you, then I would hope that you would be presenting these ideas to me for approval. Unfortunately for this assignment we cannot get approval for extra work.
    Regards, Andrew


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

    Joined: Nov 22, 2008
    Posts: 18944
    Hi Andrew,
    So, what's your conclusion? Implement the provided findByCriteria() as requested with partial-matching but don't use it? Instead, implement a new find() method that works with exact matching as Satish proposed?
    Regards,
    Marcel
    Ben Zung
    Ranch Hand

    Joined: Mar 25, 2004
    Posts: 109
    See, Andrew. That's exactly where I got confused sometimes. The specs did mention what you had quoted. One hand that's the requirements alright, on the other hand we have to make some assumptions on our own when the specs is not clear. I thought the quoted part was not too clear to me so I ended up this way.
    Is it a extra work? maybe but not too much. Here is how I did it.
    An simplified diagram of my design:

    And another purpose is trying to avoid hardcoding the "name" or "location" in client side display class.
    Given that, I figured I should define the searchable columns and that better to be done on server side and the Service would provide a interface for clients to get it through the service control. And that's done in the DataInfo, in which other server wide configuration are specified too, like the columns to present to clients when they want to create a new contractor. This make the applicaton a little more maintainable in terms of making change to column name, or add/delete a column. And columns can be
    added or taken out from the defined columns vector without ever change the client code.
    Now if this considered to be a deviation, I'd be doomed. The problem that has been bothering me ever since starting this assignment is that, I have
    hard time to balance the requirments and the reality. I've done numbers of applications for various user groups and user levels. Guess I have got used to thinking about the reality too much -- Yet another kind of training?
    Another conflicts I'd like to point out in the specs is,
    The IT director does not anticipate much reuse of the first Java technology system, but intends to use that system as a learning exercise before going on to a web based system.

    And later on:
    Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs

    I think after I roughly wrap up my assignment(another month at least), I'll check my design here one by one. I am not so sure at all now whether I have been doing things correctly and have wasted some of my time.


    Bing
    Anonymous
    Ranch Hand

    Joined: Nov 22, 2008
    Posts: 18944
    Hi,
    It's now confirmed: the search MUST be exact. I've sent an email to Sun asking for clarification:
    The question now is whether an *exact* search should be implemented or a partial-matching algorithm as the comment for the findByCriteria()method demands? In other words, should a search for a hotel with the criteria "Ocean" return only hotels named "Ocean" or also hotels such as "Ocean View" or "Ocean Resort"?

    The answer:
    The match should be exact. A search for "Ocean" should not return "Ocean View" or "Ocean Resort".

    So, the specs are clear now - there are still different ways to achive the desired behavior.
    Regards,
    Marcel
    [ April 30, 2004: Message edited by: Marcel St�r ]
    Ben Zung
    Ranch Hand

    Joined: Mar 25, 2004
    Posts: 109
    Marcel: thanks for check that out. Have you copied the full text of the answer? It is still not clear to me.
    Now since you asked the question and you got the reply as a prove, you can bravely implement that the way the reply mentioned. What about the rest of us, we don't have that information. We will go with the "Fred" matches "Fred" and "Freddy" thing.

    So your confirmation made it clear or made it unclear?
    Help please, Andrew|Phil?
    Bing
    [ April 30, 2004: Message edited by: Bing Yuen ]
    Anonymous
    Ranch Hand

    Joined: Nov 22, 2008
    Posts: 18944
    Hey Bing,
    The one sentence I posted is all I got. There was not even a "Hello" or greeting; just those two sentences.
    You are right, the answer only helped half way: the search executed by the user must return only records that exactly match what the user asked for.
    For me the conclusion is the following:
  • I will implement the provided findByCriteria() exactly as the comment in the provided interface demands -> startsWidth() and ignore case.
  • I will add an extra method findExactByCriteria() which will use equals() NOT equalsIgnoreCase() as ignoring case is no longer an exact search.
  • Furthermore, as I'm at it findExactByCriteria() will not return an array of rowIDs but rather a collection of records/rows
  • The findByCriteria() method in Sun's interface will never be used!
  • I guess this all makes sense, no?
    Regards,
    Marcel
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi everybody,
    Bing:
    Given that, I figured I should define the searchable columns and that better to be done on server side and the Service would provide a interface for clients to get it through the service control. And that's done in the DataInfo, in which other server wide configuration are specified too, like the columns to present to clients when they want to create a new contractor. This make the applicaton a little more maintainable in terms of making change to column name, or add/delete a column. And columns can be
    added or taken out from the defined columns vector without ever change the client code.

    Bing, I was wondering who on earth could help me in this other thread, and ... it looks like I just found you!
    Marcel:
    It's now confirmed: the search MUST be exact. I've sent an email to Sun asking for clarification:
    Question from Marcel to SUN:
    The question now is whether an *exact* search should be implemented or a partial-matching algorithm as the comment for the findByCriteria()method demands? In other words, should a search for a hotel with the criteria "Ocean" return only hotels named "Ocean" or also hotels such as "Ocean View" or "Ocean Resort"?
    Answer from SUN:
    The match should be exact. A search for "Ocean" should not return "Ocean View" or "Ocean Resort".
    Marcel's conclusion:
    So, the specs are clear now - there are still different ways to achive the desired behavior.

    Marcel, IMO the specs *were* clear, but you had/have two different specs:
  • Server-side, the method defined in the provided interface (and that you must *implement*) performs searchs based on partial matches. It is/was clear.
  • Client-side, the search functionality is/was clearly specified too: it must be based on *exact* matches.


  • I don't see any other solution to solve that apparent contradiction than:
  • In the Data layer, implement an additional findByCriteria() method to support exact matches OR
  • In the Business layer, use the provided method and filter the results


  • I personally prefer solution 1 because it's not more complex to do and it favours the reusability of a functionality which typically belongs to the Data layer. And for people who put the business layer client-side, there is even an additionnal argument: performance (from the viewpoint of a remote client who only needs exact matches, it's quite stupid to send him over the "wire" plenty of useless partial-match-found records just to make him filter out and reject them).
    Now, as far as solution 1 is concerned, it's easy to combine both searh algorithms to support - at the Data level - search on criteria ranges which your business layer may need (in URLyBird, I needed it to implement the 48-hours business rule efficiently). I detailed the technique I used here (see post dated November 20, 2003 12:22 AM).
    Regards,
    Phil.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11460
        
      94

    Hi everyone,
    Personally I prefer Phil's second solution, which I think is more in keeping with his three layer concept.
    The method in the Data class can do an inexact match, and a higher level method can then do any further restrictions necessary.
    This means that the database is doing the minimum amount of work. The harder work is being done on a seperate machine.
    Another reason (in my mind) for doing this is that the find() method only returns an array of record numbers - you still have to go and read each individual record seperately. This means that between the time that find() reported that a record matched your criteria, and the time you read the record, it could concievably have changed so that it no longer matches your criteria. So having an additional check at a higher level which confirms that the record still matches (and does the exact match) makes sense.
    Regards, Andrew
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Andrew,
    Personally I prefer Phil's second solution, which I think is more in keeping with his three layer concept.

    Aah... arguing with you Andrew, I haven't had that pleasure for a while now! Thank you!
    The method in the Data class can do an inexact match, and a higher level method can then do any further restrictions necessary.

    That's solution 2 indeed.
    This means that the database is doing the minimum amount of work. The harder work is being done on a seperate machine.

    It really depends on your implementation. Typically, the Data layer will have its own efficient means to access data that the business layer cannot use. Indexes for instance (back to this further).
    Now as I needed a findByRangedCriteria() anyway, to handle criteria *ranges* (findByRangedCriteria(String[] fromCriteria, String[] toCriteria)), I got my findByCriteriaExact() nearly for free. Conceptually (and simplified on purpose), it works this way:
    - findByCriteria("Fred") simply delegates to findByRangedCriteria("Fred" + 0x00...0x00, "Fred" + 0xFF...0xFF)
    - findByCriteriaExact("Fred") simply delegates to findByRangedCriteria("Fred" + 0x00...0x00, "Fred" + 0x00...0x00)
    - while my findByRangedCriteria(String[] fromCriteria, String[] toCriteria) can efficiently use my optional indexes.
    I implemented field indexes as TreeMaps mapping keys (field values) to TreeSets of recnos, which fits very well with ranged criteria (think of TreeMap.subMap()). With such a design it's as easy (a few lines of code) as efficient to return a Set of the recnos corresponding to a range of keys.
    In findByRangedCriteria(), indexed fields if any are searched first, results being combined with a Set.retainAll() (another magic stuff! ). Then, additional criteria, if any, may be handled on a subset of the whole file.
    Example:
    Let's say that your file has 50000 records, that "date" and "name" fields are indexed, but "location" not, and you need to perform a partial match search on name "Hil", location "New" for a date range of 2004-04-30-2004-05-02:
    1) Whithout any read of records (neither from cache nor from the file):
    - the 525 recNos corresponding to the date range are identified (immediate)
    - the 327 recNos corresponding to "Hilton" and "Hillary" are identified (immediate)
    - the intersection of both sets (Set.retainAll()) gives 23 recNos
    2) "Normal" search if now performed for "New" as location, but on 23 records only, possibly read from cache.
    Another reason (in my mind) for doing this is that the find() method only returns an array of record numbers - you still have to go and read each individual record seperately. This means that between the time that find() reported that a record matched your criteria, and the time you read the record, it could concievably have changed so that it no longer matches your criteria. So having an additional check at a higher level which confirms that the record still matches (and does the exact match) makes sense.

    Good point... although.
    As the business layer (wherever it is) cannot do anything with the recNos returned by find() except reading records, the time between find() returns and reads are performed will be very short. Much shorter anyway that the time spend to process the records read (especially if the user enters in the play ).
    The business layer must *read* the records to perform its additional checks (which BTW gives some additional work to the database), while the Data layer performing the same checks by itself may not need any read. So each time Data is able to return exactly the recNos the business layer needs (with no useless records to be rejected at the business layer level), while performing less reads on average than the business layer would do, the database is globally doing *less* work.
    Best regards,
    Phil.
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander

    Joined: Mar 28, 2003
    Posts: 11460
        
      94

    Hi Phil,

    Originally posted by Philippe Maquet:
    Aah... arguing with you Andrew, I haven't had that pleasure for a while now! Thank you!

    My pleasure. I always enjoy our arguments.

    Originally posted by Philippe Maquet:
    It really depends on your implementation. Typically, the Data layer will have its own efficient means to access data that the business layer cannot use. Indexes for instance (back to this further).

    True, but there is a tradeoff between having the efficient search on the database and writing "1..n" search methods in the data file. If you can have a simple generic search method in the Data class (which is what the inexact find() method is) then the Data class is easier to read / maintain.
    (Actually I suspect your ranged find might fit into the "simple generic search method" concept which will simplify use of the Data class - but then I question this assignment's need for a ranged find. )
    Of course if you are worried about network speeds and transferring huge amounts of data which may be culled at the client side, then you may want to have more efficient searches in the Data class - however this is not a consideration for this assignment .

    Originally posted by Philippe Maquet:
    Now as I needed a findByRangedCriteria() anyway, to handle criteria *ranges*


    Why do you need this?

    Originally posted by Andrew Monkhouse:
    Another reason (in my mind) for doing this is that the find() method only returns an array of record numbers - you still have to go and read each individual record seperately. This means that between the time that find() reported that a record matched your criteria, and the time you read the record, it could concievably have changed so that it no longer matches your criteria. So having an additional check at a higher level which confirms that the record still matches (and does the exact match) makes sense.
    Originally posted by Philippe Maquet:
    Good point... although.
    As the business layer (wherever it is) cannot do anything with the recNos returned by find() except reading records, the time between find() returns and reads are performed will be very short. Much shorter anyway that the time spend to process the records read (especially if the user enters in the play ).

    I agree that the time between the "find" and the "read" should be short, but no matter how short, the record could still have been modified in that time.
    That is, you are likely to be performing the following steps:
  • Check if record 1 matches criteria - if so add it to the collection
  • Check if record 2 matches criteria - if so add it to the collection
  • ...
  • Check if record n matches criteria - if so add it to the collection
  • Return list of matching record numbers


  • Unless you have the entire find method synchronised (which I advise against), there is the possibility that after validating record 1 some other client modified the record - before the record number even gets returned to the client!
    The amount of time that is available for such a modification is very small (especially if you are using indexes), but it does exist, so you should be aware of it.
    But then once you have the list of records returned, you have more work to do:
  • Read first record whose record number was returned
  • Read second record whose record number was returned
  • ...
  • Read nth record whose record number was returned


  • Again this will take a non trivial amount of time to perform. And between the time you read record 1 and the time you read record n, record n could have been modified by another client.
    Originally posted by Philippe Maquet:
    The business layer must *read* the records to perform its additional checks (which BTW gives some additional work to the database), while the Data layer performing the same checks by itself may not need any read. So each time Data is able to return exactly the recNos the business layer needs (with no useless records to be rejected at the business layer level), while performing less reads on average than the business layer would do, the database is globally doing *less* work.

    Yes, but even in your case, since you are returning record numbers, there is the potential that by the time the real records are read, the "exact match" will no longer match.
    Best regards, Andrew
    Ben Zung
    Ranch Hand

    Joined: Mar 25, 2004
    Posts: 109
    It's interesting to see you two fight. It is enlighting too.
    For this assignment,there is no way to avoid a scan over the file when doing find, like doing table scan in a relational database where there is no index created. And even worse with the provided DB interface. What is the point to return the record number instead the record itself?
    You got the record when during comparison already and a record number returned and the called has to go into the data to read the record again.
    That's a waste of everything.
    I have, before this discussion, implemented Sun's DB find but it is not used(like some of ranchers do here). I noted this in the choices.txt. Now I am sure that this would work after all this discusion and my being lost and found. My own find is a overload of sun's. it takes a boolean indicator to do either exact or not-exact search. And it returns a string array with and later packed in a contractor object and presented to the client.
    Thanks for clears things up regarding the search exact/non-exact.
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Andrew,

    (Actually I suspect your ranged find might fit into the "simple generic search method" concept which will simplify use of the Data class - but then I question this assignment's need for a ranged find. :tongue: )

    I think you suspect well.
    Of course if you are worried about network speeds and transferring huge amounts of data which may be culled at the client side, then you may want to have more efficient searches in the Data class - however this is not a consideration for this assignment .

    That's still the question of the right tradeoff to find in order to be OK with this excerpt of the instructions:
    A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient.

    Supporting optional indexes is more complex (but still understandble by junior programmers I guess), but much more efficient. To be justified in choices.txt anyway.

    Why do you need this? (findByRangedCriteria()):

    To efficiently support the 48 hours business rule.
    Yes, but even in your case, since you are returning record numbers, there is the potential that by the time the real records are read, the "exact match" will no longer match. :tongue:

    Agreed, but as it's a no-solution issue...
    Best regards,
    Phil.
    [ May 03, 2004: Message edited by: Philippe Maquet ]
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Bing,
    It's interesting to see you two fight.

    Fight? I cannot even imagine fighting one day with Andrew!
    For this assignment,there is no way to avoid a scan over the file when doing find, like doing table scan in a relational database where there is no index created.

    Don't forget that you're just given an interface. And you're free to implement it as you want, including indexes if you feel it's worthy.
    What is the point to return the record number instead the record itself?
    You got the record when during comparison already and a record number returned and the called has to go into the data to read the record again. That's a waste of everything.

    100% agreed. Unfortunately, that's what we are expected to do given the provided interface.
    I have, before this discussion, implemented Sun's DB find but it is not used(like some of ranchers do here). I noted this in the choices.txt. Now I am sure that this would work after all this discusion and my being lost and found. My own find is a overload of sun's. it takes a boolean indicator to do either exact or not-exact search. And it returns a string array with and later packed in a contractor object and presented to the client.

    I think it shoudl be accepted, as far as the original find method you were expected to implement works as expected by SUN.
    Best regards,
    Phil.
    Anonymous
    Ranch Hand

    Joined: Nov 22, 2008
    Posts: 18944
    Hi Philippe,
    I'm jumpin' back into this topic...unfortunately, this BB doesn't allow branching. I want to reply to the specific post you wrote on May 1st.
    I implemented field indexes as TreeMaps mapping keys (field values) to TreeSets of recnos, which fits very well with ranged criteria (think of TreeMap.subMap()). With such a design it's as easy (a few lines of code) as efficient to return a Set of the recnos corresponding to a range of keys.

    I planned to use the same strategy for my indexes. However, I'm a little stuck I would say. One needs to loop through the criterias...and then? How do you match one criteria (e.g. criteria[n]) to an index? Different question, how do you know that there's an index for the particular criteria? After all, the indexed fields need to be searched first.
    Regards,
    Marcel
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Marcel,
    Sorry to reply so late.
    I planned to use the same strategy for my indexes. However, I'm a little stuck I would say. One needs to loop through the criterias...and then?

    I store the field numbers corresponding to *used* criteria in an ArrayList.
    How do you match one criteria (e.g. criteria[n]) to an index?

    I implemented my indexes in an Index class. I've defined a MetaData class which owns a collection of Fields. And each Field may own an Index (so an indexed field is just a Field whose Index instance is not null).
    Different question, how do you know that there's an index for the particular criteria?

    I think it's the *same* question.
    After all, the indexed fields need to be searched first.

    Good catch, and that's what I do. I just needed to sort the ArrayList I mentioned above:

    Regards,
    Phil.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: name and/or location search