• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: URLyBird 1.1.3 Find criteria

 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
I started this assignment just over a week ago and most of the questions I've wanted to ask have already been answered at the ranch. Thanks!
However, I'm still not sure about the find criteria in the DB interface provided by SUN...
// 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);
Now, if criteria[n] is "ca" and value[n] is "The cat sat on the mat", should the search succeed because one word in the value String starts with "ca"? Or should this search only succeed if the whole value String begins with "ca ..."?
Similarly, for the user interface SUN say that...
"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."
Now does exact match mean that if the user specifies "cat" then a String value that exactly equals "cat" is the only match allowed. Or does it mean that any String that contains an exact match for "cat" should be classed as a match (e.g. "The cat sat...").
I'm currently taking the simplistic approach of using String.startsWith() for DB interface, and using String.equals() for the user interface. I've also used regex for both but backed of when I realised I wasn't sure if I'd interpreted the spec properly.
Any opinions or alternative interpretations?
Cheers
Gareth.
 
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gareth:
In regard to question one:

Now, if criteria[n] is "ca" and value[n] is "The cat sat on the mat", should the search succeed because one word in the value String starts with "ca"? Or should this search only succeed if the whole value String begins with "ca ..."?


I interpret

For example, "Fred" matches "Fred" or "Freddy"


to answer that rather definitively. It's a prefix search.
In regard to question two:

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.


Perhaps the important thing is how you document your understanding.

This document deliberately leaves some issues unspecified, and some problems unraised.

I'd bet you could interpret it either way.
My assignment is URLyBird 1.2.1 and to be difficult I interpreted it as an exact search. This made more work for me, and I don't recommend it.
Tx
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm currently taking the simplistic approach of using String.startsWith() for DB interface, and using String.equals() for the user interface.
Sounds good. In fact the user interface can call DB's find() (or whetever it's called in your instructions) as a first step, to get both "Fred" and "Freddy"; then loop through the results and use equals() to check for an exact match.
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim
That's pretty much what I'm doing except I put an adapter between the client and the DB implementation. The adapter provides a simple interface that meets the requirements of the client and performs the necessary mappings between the client and DB. I didn't see anything that suggested the client must use the DB interface directly.
Bob
I didn't understand your answer to question 1. What do you mean by prefix search?
Cheers
Gareth.
 
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gareth,
Jim said:

Sounds good. In fact the user interface can call DB's find() (or whetever it's called in your instructions) as a first step, to get both "Fred" and "Freddy"; then loop through the results and use equals() to check for an exact match.


To satisfy requirement "exact mach" I do it a bit easer: I take elements in String[] and feel the rest part of each element with blanks and only then send a request. Instance:
You write "Fred". I take "Fred" and feel the rest (64-4 = 60) 60 positions with blanks:
"Fred ...."
In the case you get the correct response from the Data without need to filter it.
Cheers,
Vlad
[ July 17, 2003: Message edited by: Jim Yingst ]
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's an interesting approach. My instructions say though that the DB file's fields are null-terminated. Even though in practice, all fields in the sample file are currently terminated with spaces. So that makes me think that other applications could insert fields with NULL chars (value 0) at the end, and these are valid fields we should be able to handle. I've dealt with this by trimming all fields when they're used in comparisons - I've decided that whitespace was not intended to be considered when clients ask for an "exact match". I'm not sure how an approach like yours can be combined with my interpretation. (Which may be wrong, but it's what I believe currently.)
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim/Vlad
I've made the same assuption as Jim. I trim the criteria and value before startsWith/equals to (hopefully) avoid any problem with white spaces or nulls. I'm not saying it's the right approach. Just the one I've take so far. I need to think it through some more before a final decision.
Thanks for the response.
Gareth.
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gareth:
A "Prefix search" matches the start of the string, such as Fred matched the Fred prefix in Freddy.
Another way to do the "exact search" is to send a null-terminated search string to the database, which signals the database to perform that type of search. Of course, you should have the null-terminated specification on database fields as part of your assignment.
Of interest, since the instructions state that fields that are only partially filled are null-terminated, there can be only two explanations for the blanks in the database: Either blanks are important or the database is corrupt.
I think you also must consider capitalization, which isn't important for either names or locations (i.e., ever see a telephone book where capitalization is important?). I don't thinks it's correct to match either blanks or capitalization.
There even are a couple of other flacky issues with the DbAccess interface's search procedure, but it's the issues that make the assignment interesting!
Yx
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Bob
Your post has got me worried now. I did a search on US-ASCII encoding here and found that Jim and a few others are dealing with this issue very differently. The data file provided by SUN does not have any nulls in it (which I found strange) so I ignored the issue until I got the basic framework running. I've been using valueString().getBytes(US-ASCII) before I write the bytes (padded with white space) to the FileChannel, and use new String(buffer.array().trim() once I've read them from the FileChannel. This works with the file I was given and the records I create look exactly the same as records provided in a Hex editor. My concerns are that the original file may have been given by mistake (no nulls!), and that I'm not sure how to create a null terminated US-ASCII byte[] in Java (takes me back a few years to C/C++). The ranch threads don't seem to go into the lack of nulls in the data file or how to null terminate Strings (unless I've missed something?).
Sorry if this has been covered already. Any help appreciated.
Gareth.
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gareth:
I think the assignment database is corrupt, and I wrote that in my choices document. (I haven't received my score yet, so I don't know if SUN accepted this argument).
You can create a null-terminated byte array:

I think you should null-terminate any string whose length is less than the field length.
Tx
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Bob
I will follow your lead. Seems a bit harsh of SUN to give us a corrupted file though.
Cheers
Gareth.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Corrupt" seems an overstatement, I think. There's nothing wrong with having spaces at the end of a field, according to the API. An entry like
"Freddy          "
is perfectly legal. There are questions, though - e.g.
(1) If someone searches for an "exact match" to "Freddy" (with no spaces), should they find the above entry (with spaces)? I think with a very literal reading of the requirements the answer is "no". However in this case I am willing to let common sense override a literal interpretation - "Freddy" matches "Freddy          " in my program, because that's what any user would expect, I think. Users don't read specs after all.
(2) If a user enters a new value for a field with no spaces at the end, should we save the value with no spaces, or should we add spaces to match the other entries in the sample DB?
I prefer to add spaces, because (a) it's legal to have spaces, accordig to the spec, and (b) I think that the sample DB file is probably a better indication of how the file is really used than the specs are. Evidently the other real program(s) that use this file are used to having spaces, not NULL chars. Why rock the boat now?
----
Now having said this, it's still important (IMO) to support the possibility that some future programs will insert NULL-terminated strings into the DB file, since that's perfectly legal in the spec. So for testing I insert some myself, and then check to make sure that they can be read, found, updated, locked, unlocked, and deleted, just like "normal" records.
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim
My spec says...
All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field. The character encoding is 8 bit US ASCII.
The file I've been given doesn't conform to that spec. None of the text values are null terminated. I agree that we just have to deal with whitespace and nulls, but can't understand why they've done this. Not annoyed, just puzzled.
Cheers
Gareth.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
null terminated if less than the maximum length for the field.
Technically they haven't violated this. They've just used the maximum length of the field, by padding with spaces. I agree it's not what was probably intended when the spec was written, but it's not quite a violation as I see it.
but can't understand why they've done this.
I believe that they are trying to simulate typical semi-clueless customers, who say one thing but actually need something else. This is in fact the type of challenge that a developer actually faces, and it seems to be something they want to test us on. Though I'm not sure how they grade it. Probably there are several acceptable strategies, but the key is that you document the problem and your resolution, and that the user's experience should not be too counterintuitive.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hallo Jim, Hallo Gareth,
Jim said:

I've decided that whitespace was not intended to be considered when clients ask for an "exact match".


Why have you decided it?
It is not explicitly said. So, I beleive exact means exact!
Vlad
 
Bob Reeves
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All:
This reminds me of the earlier versions of RS-232 when everyone had their own RS-232 implementation, and none co-operated!
I prefer to follow the robust receiver/strict transmitter principal: accept a range of inputs, but send strict to the spec. That implies that the null-terminated field should be saved.
I exact matched exclusive of the blanks too, but I think now that was a mistake. The blanks are valid ASCII, and probably should be treated as what was intended. Luckily, the prefix search finds the entry -- blanks or not.
Normally, one should always follow a spec, or have the spec changed. It's very questionable policy to "implement what is done" against a spec. I think the only valid way to implement the don't care" blanks is to have SUN agree to a spec amendment. That's how it's done in "real life".
Gareth, you might want to send an inquiry to SUN.
Tx
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I think I've done this to death and believe I can now justify what I've implemented. You've all been very kind and helpful.
Many thanks.
Gareth.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[Vlad]: Why have you decided it?
It is not explicitly said. So, I beleive exact means exact!

Well, imagine this conversation:
Customer: Your program doesn't work. The search feature always comes up blank, no matter what I type.
Programmer: Well, let's look at an example. What exactly do you try to search for?
Customer: I enter "Buonarotti & Company" in the name field, leave location blank, and press the "Search" button. It comes up blank. I know that "Buonarotti & Company" is in the database because I've seen the name when I press "See all records", and I was careful to use the right spelilng and capitalization.
Programmer: OK, good. Let's see... Ah. It seems that the value in the database is actually "Buonarotti & Company            " with 12 spaces at the end. To find them using exact match, you need to specify the exact number of spaces at the end.
Customer: What? You're joking.
Programmer: Well, the spec said you wanted to find things using an "exact match", so that's what I did.
Customer: How am I supposed to use this thing? Didn't you apply some common sense? :roll:
Programmer: Oh, it's not so bad. You just keep adding spaces until you've filled up the entire field length...
Customer: You couldn't write the program to do that for me?
Programmer: Well, that would interfere with your ability to do an exact match. What if you wanted to search for "Buonarotti & Company           "
(11 spaces) and the program returned "Buonarotti & Company            " (12 spaces). That would be an error; can't have that.
Customer:
[ July 18, 2003: Message edited by: Jim Yingst ]
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim
Well,
first: I would never argue with customer.
second: I would suggest him to reconsider the specification!

Honestly saying I skipped the following words in specs(mentioned by Gareth) :

All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field.


So, I will think about . Probably you are right.
Cheers,
Vlad
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bob
I've posted a request for clarification to SUN. I'll post the reply here (if I receive one).
Cheers
Gareth.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanx Gareth!
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Jim said:

... some future programs will insert NULL-terminated strings into the DB file, since that's perfectly legal in the spec. So for testing I insert some myself, and then check to make sure that they can be read, found, updated, locked, unlocked, and deleted, just like "normal" records


I have three questions:
1) How did you handle that? I a record in DB is null-terminated than and you accept it without parsing on client it will be shown in this way : "ABC(+small square for null)".
Does it mean that you have also parser
Or
on client? or U do it on the server before the a response to the client? Ho
2) What should the server by update or create if one or more elements in String arrays are nulls. At the moment I filled these values with blanks, but it seems I should just create a null-terminated String containing only 0x00.
3) If assumption 2 is correct, How do you provide "*" wildcard search. I expended the functionality by offering also to search the database by all fields. I used for "any value" an emty string.

Vlad
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Vlad.
1) Does it mean that you have also parser
Yes, like that.
2) What should the server by update or create if one or more elements in String arrays are nulls.
Careful, we've got two types of nulls here - NULL chars, which we were just talking about, and null references, which is what people usually mean when they say "null" in Java. I will differentiate the two via capitalization.
If you mean a null reference, as in

then I would say that's a NullPointerException. The API says "the new value for field n appears in data[n]". To me that means no null reference - an actual String instance must be there. An empty string "" would be a legal value, represented by all NULL characters (or one NULL char followed by anything; remaining chars shouldn't matter once a NULL is found.)
If you mean what should we do if one or more of the characters in a String is a NULL char, I would consider that an IllegalArgumentException. We have no way to represent a NULL char inside a String in the DB file, because the NULL char would signal the end of the String. To be honest though I haven't checked for this situation in my code, because none of the code that calls update() is capable of inserting NULL chars into a string. I suppose it would be a good check to include for safety though.

3) If assumption 2 is correct, How do you provide "*" wildcard search.
I'm not sure what you mean. If the user wants to view all fields, that's done with

If the user wants to search using exact match, that's done with

I expended the functionality by offering also to search the database by all fields. I used for "any value" an emty string.
My instructions for the find() method say that a null reference indicates that any value for that string is OK. I.e. don't bother checking that field for the search; just use the non-null criteria. If all criteria are null, return all rows. This is how my find works. However my GUI doesn't use it for anything other than (a) finding all records, (b) finding an exact match for name &/or location. I may also offer a more general search using startsWith() (already implemented for find(), but not required for the GUI). I'm not going to offer a wildcard search, other than the startsWith(), which is like having a wildcard at the end. E.g. I will allow a search for "Fred*" but not "Fre*y". The customer has already dictated the way find() should behave; I'm willing to offer additional search functionality that uses the find() functionality. But an arbitrary wildcard search is too different from the find() functionality, and was not requested, so I'm not doing it.
If I were designing a real system with more robust searching I would probably want a new find() API, something like find(SearchCriteria crit) where SearchCriteria is a more general interface:

This would allow the construction of a wide range of different search options. But the existing find() API is too limiting for real use; I'm not really interested in enhanced searches using that API if they're not required.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,
Sorry, I have ask the question in a stupid way.
1) Yes, I ment null refence:
How should the server handle request with null referenced Strings:
Intance:
update{null, null, ...}
create{null, null, ...}
Throwing NullPointerException it is something like having an option for each field in real database (Oracle, DB/2): NOT NULL.
Seems, that you consider it this way.
Instead of trowing NullPointerException I filled in this case all null fields with blanks and saved them, but you are probably right, we shouldn't.
2) Lets take following usecase:
- client sends request to read.
- servers reads a record, which has a null-terminated (not null referenced) Strings.
- server sends response to the client {"abc0", "def", "..."} (0 is byte 0x00).
- clients Parser recognizes 0x00 and takes it away, so that the GUI shows only "abc".
- client changes second string "def"->"dexxx" and sends request to update the record.
- servers receives a request. One of the strings is "abc". It has no clue that it was null-terminated string and takes "abc",fills the with blanks and saves it:"abc ".
At least I have done this way and I guess I too (As you said that you fill the rest of strings by update and create with blanks).
That means that the record has changed from "abc(0x00)" -> "abc " without explicit indention of the client to do it.
Analazing it all I beleicve that it would be better to make 2-way parser on server (not on the client). In that case the server will add 0x00 to requests such as update and create and will take it away before sending to the client.

What do you think about it?
Vlad
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello again, Vlad!
Throwing NullPointerException it is something like having an option for each field in real database (Oracle, DB/2): NOT NULL.
Seems, that you consider it this way.
Instead of trowing NullPointerException I filled in this case all null fields with blanks and saved them, but you are probably right, we shouldn't.

Well, that works too - it's just not what I did. The spec's ambiguous here, so use your judgement. I like to write code so that if something fails, it fails spectacularly, so it's easy to find the problem. This is good during development but maybe bad in production. (Unless you've tested enough to know that the failure will not happen.)
2) Lets take following usecase:
- client sends request to read.
- servers reads a record, which has a null-terminated (not null referenced) Strings.
- server sends response to the client {"abc0", "def", "..."} (0 is byte 0x00).

Ah. No, my own server wouldn't do that. When it reads the first NULL char it interprets that as a signal that the String has now terminated. So the server would never send "..."; it would send "" (an empty string). When you asked if I parsed for nulls, yes I do - but in the server, not the client.
If the other fields do not have NULLs, then my server will send the entire String including trailing spaces. My server is very picky and follows the specs exactly, without applying any "common sense" to customize to what the customer really needs.
- clients Parser recognizes 0x00 and takes it away, so that the GUI shows only "abc".
Well, if the field had been "abc       " then my client would trim it and display it as "abc", so that's similar enough that I'll continue with that example instead...
- client changes second string "def"->"dexxx" and sends request to update the record.
At this point my client would insert additional apces at the end, up to the length of the field. So we'd get "de        " sent back to the server.
- servers receives a request. One of the strings is "abc". It has no clue that it was null-terminated string and takes "abc",fills the with blanks and saves it:"abc ".
Using my current client, this won't happen. But if someone rewrote the client to send "abc" rather than "abc       ", the server would save "abc" as "abc.......".
This isn't necessarily the best way to organize client/server responsibilities, but it's what I did.
Anyway, whether you do it in the server or in the client - I prefer writing the code so that future DB records will look as similar as possible to existing records. Which means that all fields will get padded with spaces. If some other application puts in NULLs rather than spaces, that's OK, my app will understand. But if my app reads and then re-saves the record, the NULLs will get converted into spaces.
Analazing it all I beleicve that it would be better to make 2-way parser on server (not on the client). In that case the server will add 0x00 to requests such as update and create and will take it away before sending to the client.
What do you think about it?

Sounds good. Probably it's better to let the server control this; I'm just too lazy to change this part of my code now without a compelling reason.
[ July 21, 2003: Message edited by: Jim Yingst ]
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,
[Jim] I like to write code so that if something fails, it fails spectacularly
I like that!
Ok, I have done 2 way parser on the server tp follow the specification. One more question: I did wanted to have fices format field in the file.
Let's say cutomer id can be max 6 bytes.
Th request for update from the the client contains the fiel "123";
If the server just add one null byte "123(0)" I will loose fixed format of the fields.
To avoid it I add 3 nulls to the of the string "123(000)", so that I have 6 bytes. In case case I have still fixed format in the database.
Is it Ok interpreting the requirement for null-terminated string by adding not only null byte to the end, but filling all the rest with null bytes?

Vlad
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vlad...
Is it Ok interpreting the requirement for null-terminated string by adding not only null byte to the end, but filling all the rest with null bytes?
Yes, I think either one is acceptable. My understanding of the term "NULL-terminated" (from the world of C) is that the first NULL indicates the end of the String. It doesn't matter what comes after that; it should be ignored anyway.
Note that this means that the trim() method cannot be guaranteed to read a NULL-terminated string correctly. Let's say you have a record
abcdefg...
and you overwrite it with
ABC.
The record now appears as
ABC.efg...
If you grab all 10 bytes, convert to String, and trrim(), you get
ABC.efg
when what you really want is
ABC
So I think it's necessary to use indexOf(0) to find the fist NULL, rather than merely trimming the last. Even if you code always fills unised bytes with NULL
ABC.......
there's no guarantee that other processes which interact with the file will also do this.
(Other processes may not interact with the DB file concurrently with our program - but they might process the file while the server is shut down.)
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,
I never programmed with C, so thanx a lot.
In my case I don't need to trim because I have done it on server
I read all records in constructor, cut off null and the rest part and save all record in the cash as they are supposed to be shown on the client.
One more thing. All of you used String.indexof(0) to indicate null. As I first read a bytes from file (and only convert them into String) catch this null already from bytearray using "for" cycle. (The the applies for write: I do on the before I write bytes). One of the reasons was that I am not sure that
byte[] b[x] == 0x00 and String.indexOf(0);
Can you really be sure that 0x00 will be correctly interpreted by indexOf(0) on String with all encodings?
Vlad
 
Gareth Knowles
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All
Just had a reply from SUN.
I asked...
Which of these is closest to the truth:
a) The file is valid. You've just used the maximum length of the field by padding with spaces and I should do the same. i.e. You are are trying to simulate typical semi-clueless customers, who says one thing but actually means something else.
b) The wrong file has been distributed for this assignment (either by mistake or deliberately) and I just have to document the fact and deal with it.
c) I should realise there is a problem with the file and negotiate a spec change with you.
d) The file and spec are perfectly correct and I should be able to deal with records padded with whitespace, but when I write records I should always write null terminated Strings.
They said go with (a).
HTH
Gareth.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vlad.
I never programmed with C, so thanx a lot.
You're welcome. Some Java books use the terminology too when they explain Strings - they start by saying "unlike in other languages, Java strings are not null-terminated". Which is helpful to know, if you know the other languages, but confusing otherwise.
In my case I don't need to trim because I have done it on server
Yeah, same here. But even on the server, some people might want to use trim(). My comment here was actually for S Bala, after I read this post and then your own post reminded me of the issue.
I read all records in constructor, cut off null and the rest part and save all record in the cash as they are supposed to be shown on the client.
Me too.
One more thing. All of you used String.indexof(0) to indicate null.
Actually I didn't use indexOf() either, I just figured that was close enough to what I did that for discussion, it was easier to talk about indexOf(). I was reading from a CharBuffer at the time, so the actual code is:

As I first read a bytes from file (and only convert them into String) catch this null already from bytearray using "for" cycle. (The the applies for write: I do on the before I write bytes). One of the reasons was that I am not sure that
byte[] b[x] == 0x00 and String.indexOf(0);
Can you really be sure that 0x00 will be correctly interpreted by indexOf(0) on String with all encodings?

Not for all encodings, but it's true for all single-byte encodings I'm aware of, and most especially it's true for any ASCII-based encoding such as US-ASCII, ISO-8859-1 (Latin-1), Cp-1252 (Windows ASCII). Those are the ones I think it's worth considering, since the spec says US-ASCII. I figure it's not unusual for a customer to want to change from US-ASCII to Cp-1252 for example, but if they want to change to EDBIC, or something for Cyrillic or Devangari alphabets, I won't be responsible for the results.
[Gareth]: Just had a reply from SUN.
I just replied here.
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vlad and Jim,


Vlad:
As I first read a bytes from file (and only convert them into String) catch this null already from bytearray using "for" cycle. (The the applies for write: I do on the before I write bytes). One of the reasons was that I am not sure that
byte[] b[x] == 0x00 and String.indexOf(0);
Can you really be sure that 0x00 will be correctly interpreted by indexOf(0) on String with all encodings?
Jim:
Not for all encodings, but it's true for all single-byte encodings I'm aware of, and most especially it's true for any ASCII-based encoding such as US-ASCII, ISO-8859-1 (Latin-1), Cp-1252 (Windows ASCII). Those are the ones I think it's worth considering, since the spec says US-ASCII. I figure it's not unusual for a customer to want to change from US-ASCII to Cp-1252 for example, but if they want to change to EDBIC, or something for Cyrillic or Devangari alphabets, I won't be responsible for the results.


In my Field class, here is how I get a String field value from the record ByteBuffer :

As I look for the zeros after converting to a String, I suppose that I am not concerned by the encoding. Right ?
Best,
Philippe.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim/Phil,
I think it is Ok, I just have done it anyway with array of bytes, but not with array of chars or string to be completely independant from platform and its encoding.
Vlad
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seems like either way should work. If someone tried to use an encoding in which a NULL char was represented by something other than 0x00, then I think the code Philippe & I use is safer, since it looks for NULL after converting to chars - it will understand NULL however it was represented in bytes. But this is a very minor point, IMO - the only encodings I think are worth worrying about are ASCII-based, and for those, 0x00 == NULL, always.
 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gareth Knowles:
Hi All
Just had a reply from SUN.
I asked...
Which of these is closest to the truth:
a) The file is valid. You've just used the maximum length of the field by padding with spaces and I should do the same. i.e. You are are trying to simulate typical semi-clueless customers, who says one thing but actually means something else.
...
They said go with (a).
HTH
Gareth.


Hello all--
Just wanted to ask everyone who has been working on the GUI if they've been interpreting the GUI specs loosely concerning the "exact criteria search" as it seems should be done according to SUN's email response to Gareth's email above. Right now I have a semi-exact match going - it matches whitespace at end (b/c I trim() the field input) but it's case-sensitive (are there any other characteristics i should be lookin at? ). So I guess at this point I am partially-loosely interpreting the specs as I am assuming the client meant that the search should match the input that is visible exactly with what is in the database.
You know, if SUN is really trying to simulate semi-clueless users, then what if this whole spec is inaccurate? What if the user reaaaally wanted something done in C++ instead!?!?!?!?!
Just kidding.

Paul

[ October 24, 2003: Message edited by: Paul Tongyoo ]
[ October 24, 2003: Message edited by: Paul Tongyoo ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic