Adam Caldwell

+ Follow
since Mar 27, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Adam Caldwell

Note it as a design decision that you didn't fix it and leave it at that.
I think you need to go back and re-read the requirements and then rewrite your code because you aren't implementing the requirements corectly (irregardless of the fact that you have a bug in your code).
The requirement is to parse something of the form key1=val1,key2=val2,key3=val3 and see if any records match it.
What you have written is something that breaks up the string into key=value strings and then compares the value to the n2-ith data value returned from readRecord().
You need to first figure out which indexes key1, key2, and key3 map to in the array returned by readRecord and then string compare the value at that index with the n-th value string.
Also, if you have any further problems, be sure to include which line number you are getting the error on so that we can help you track down your error faster.
One other thing, you should also add some System.out.println() to your code to print out what tokens it's parsing... If you do that, you'll get a clearer idea of what your program is doing.
[ June 02, 2002: Message edited by: Adam Caldwell ]
In mine (using Sockets & Object Serialization), close simply closed the ObjectStreams and the Socket. After that, any calls to the "RemoteData" object resulted in Exceptions (which is the behavior of the Data class should you call methods after close is called).
I implemented close() as closing the remote connection, not closing the database. It seems that having the "Data" going away whenever there are no clients and then coming back when there are clients is incredibly wasteful of resources.
The Data class is not a "known working class"... Take the null's bug in it that we've discussed here before as well as the deprecated methods... You need to modify the class anyhow.
My method was pretty complicated since I handled the case where they sent in Key=value,Key2='value2 ',Key3=Value3
The spec wasn't clear on if the format was key='value' or key=value, although the example showed key='value'.
My algorithm was similar to:
Look for equals sign (key=st.nextToken("="))
Make sure key is valid. If not immediately return null (per spec).
Skip the equals and get next token (st.nextToken("=',"))
value = st.nextToken();
if (value is ')
handle as quoted string

tuck key id and value into an ArrayList
Skip the comma
Speaking as someone who got all of the points on the server portion (although I didn't use RMI), I did not handle the case where unlock was never called.
In my design document, I acknowledge the fact and said that if this were for the "real world" something would have to be done to fix the problem.
Since this assignment isn't the real world, you can safely dismiss the flaw in your code.
You can provide your documentation as HTML (except for the README.txt) and get all of the documentation points. My user documentation, client documentation, and design docs were all in HTML format and I got 20/20 on the doc portion.
You won't loose points for implementing it. The way the instructions are written, unlock(id) unlocks the record specified by the id... Since id=-1 specifies the entire database, that could be seen as a requirement to implement it....
In my code, unlock(-1) only required a few extra lines of code, although I never called unlock(-1) from anywhere in the code.
The requirements only specify that you need to do equality comparisons in the very specific format that they specify.
What this requirement really means is that they want to make sure that you know how to use string tokenizer.
Here's how I implemented it:
1) complexFind(ArrayList). Took an ArrayList of key value pairs (key = integer id of field, value=string to compare to). The implementation of this function was actually copied from find() and modified to look for more than one key. find() was rewritten to call complexFind.
2) criteriaFind(String) tokenized the string and created the ArrayList to pass to complexFind.
Are you sure you got all of the inner classes? You should probably do FBNGui*.class to make sure you get all of them. Also, to make sure you're not flirting with a classpath problem, you can explicity specify the jar file:
java -jar client.jar cmd_line_args
Also, you manifest looks wrong... you have / instead of .
Mine looked like:
Main-Class: suncertify.gui.FlyByNightGui
I come from the unix command line world too. I
expect that if I put on the command line 'foo ' that the trailing space will be preserved. If I put foo bar, I expect the shell to get rid of the extra space.
Here's a real world example though. Say you were storing paragraphs of a book in a database, and you put in " This is the first paragraph." You would want those leading spaces preserved wouldn't you? Well .trim() removes spaces from both ends of the string.
And btw, the encoding used in the deprecated method is NOT UTF-8. It is stripping the high byte off and replacing it with 0. That particular mapping is the same as UTF-8 for any character less than 127... which just so happens to be the same as for US-ASCII.
Either answer is correct for reading the stuff back in, the question becomes what happens when you write stuff out. Under the US-ASCII encoding, any non-ASCII characters get converted to ?, under UTF-8, you get the multiple byte encoding problem.
I personally don't like either solution, and I said as much in my design decisions, noting that I could not fix the problem given the requirements.
I personally think that any database that doesn't give me back what I put into it is inherently broken.
That being said, I cheezed out on the assignment and just used .trim()
The field length is a fixed number of bytes based on FieldInfo.length(). Unicode is 2 bytes per character. UTF-8 is 1-3 bytes per character.
Now the code to write the data to the file says:
space = description[i].getLength();
size = newData[i].length();
toCopy = (size <= space) ? size : space;
The toCopy is a number of BYTEs, not characters.
So when you do the newData[i].getBytes(0, toCopy, buffer, offset); (or whatever you replace this with), it ends up copying that many bytes.
Now, if the code you replace it with uses UTF-8 and the string you're trying to copy ends up being newData[i].length() characters, but the last character is a character that requires a multi-byte encoding, you'll end up truncating that final character into something that isn't valid in UTF-8 when you try to read it back in.
Does that make sense?
BTW, you should document that there is a bug in that code anyway... It needs to store the length otherwise when you read the string back in, its possible you will loose real infomation... The standard "fix" people say is to add .trim(), but what if the data contains trailing white space that is supposed to be there? What is the correct way of fixing it?
If you assume that lock and unlock are done in the same thread, then the simplest way to keep track of whether or not you currently have the lock is to use Thread.currentThread() to obtain a Thread object for yourself and then save that away on the lock() and then make sure on the unlock() make sure that LockOwner(id)==Thread.currentThread()