B&S db file meta data, padding

[Nikolay Elenkov]

Hi,

I just started doing my B&S assignment and, naturally, there are a few unclear points. So, I thought I'd get a second opinion

Firstly, there's the magic cookie. Do I just ignore it or throw an exception if the file does not start with the correct cookie? Anyone done that?

Then, there is record padding. I've looked at the supplied file and all records are space-padded(0x20), but in the instructions it says:

... null terminated if less than the maximum length for the field.

So, should the records I add in create() be space-padded too? What are you guys doing?

And one last question. I am implementing my data access class using maps for metadata and records (name->length, name->value) so theoretically it should be able to read any file in the specified format regardless of the number of fields and their sizes. Do you think that's overkill and I should just stick with reading the 6 supplied fields?

Any comments appreciated.

TIA

[Jared Chapman]

Hi Nikolay,

Firstly, there's the magic cookie. Do I just ignore it or throw an exception if the file does not start with the correct cookie?

I read the cookie and store it, but ignore the value. I don't recall any specifications on what specific value(s) would signify this as a valid or invalid data file.

So, should the records I add in create() be space-padded too? What are you guys doing?

I am space-padding when i create a record. None of the records in the database that Sun supplied me have null-terminated Strings - they're all space-padded. So I go right along with that.

I do not assume, however, that all the records in the future will be space-padded, since the specifications say that the database file is used by another custom-written application. Granted, this custom application is simply used to write reports, and I can't imagine why that kind of program would modify the data in the database file (i.e. add a new record with null-terminated strings). But, better safe than sorry.

So this is what I did. When I create a record, i pad all the fields with spaces. When I update a record, I pad the spaces of the FIELDS that I'm updating, and skipping over (NOT overwriting) the fields that aren't changing.

[Nikolay Elenkov]

Thanks for your comments.

Not modifying the fields you didn't create is a nice idea. I think I'll do the same. As for the cookie, it really doesn't say nothing in the instructions, so I guess I'll just save it in a field for whoever is interested

[Jared Chapman]

Speaking of space-padding, here's another issue to consider:

The int[] find(String[] criteria) method in the Data class is supposed to return the record numbers of those records where field[n] begins with criteria[n].

The specifications for the user interface, however, state:

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.

This leads me to believe that you must filter the results returned from find(String[]) to remove the records that dont EXACTLY match the user input.

In reading other posts on this topic, some people have argued that this exact match criteria means that if a user enters "Fred", then the field must be exactly "Fred" to be a match, as opposed to "Fred ". I don't understand the point of that. I just trim the spaces off the end of the values and compare them.

After all, can you imagine a new fast-food company coming out and calling themselves "McDonald's ", and arguing in court that their name is not the same as "McDonald's" because theirs has a blank space at the end? I don't think sun intended exact to be interpreted quite so exactly.

[Jared Chapman]

I will either implement my search (on the GUI) by either using JComboBoxes, where the user is supplied with all possible names and locations, or by using JTextFields and radio buttons where the user can specify an "exact" or "begins with" search. Either way, as long as the user remembers part of the name/location, they can perform an effective search. And padded spaces and character case is ignored, btw.

[Robert Hayes]

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.

To apply this to real life... it's not unusual for a client to create a spec that is wrong; or ambiguous. In this case, our client may THINK that their DB is full of null-terminated fields. But when you look at the data it isn't. Or, do they know that it isn't and wrote the spec in such a way as to mean "it should be"?

Normally this is where I go back the client and say: clarify what you mean. But we can't

I've had specs like this before IRL. My tendency is to code to what is written in the spec, because when the client comes back and says: "Did you code to spec?" I can say "Yes". Not, "Yes, but I discovered something that didn't really make sense, and so I did it this way instead -- that's what you meant right?"

My project reads both null and non-null terminated strings... and writes null-terminated strings if the string is shorter than the field size.