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 ..."?
For example, "Fred" matches "Fred" or "Freddy"
It must allow the user to search the data for all records, or for records where the name and/or location fields exactly match values specified by the user.
I'd bet you could interpret it either way.
This document deliberately leaves some issues unspecified, and some problems unraised.
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.
I've decided that whitespace was not intended to be considered when clients ask for an "exact match".
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.
... 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
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.
Originally posted by Gareth Knowles:
Just had a reply from SUN.
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).