For this task we continued working with Restlet and Wicket, but we added a persistent database into the mix this time. In the previous set of katas, the database we used was not persistent and the contacts would be wiped out when the program was quit. To maintain persistency in our system, we decided to use the embedded database system Berkeley DB. Because Berkeley DB is embedded, the database is stored within our contact system allowing our contacts to be persisted unlike our previous system.
For the first half of the exercise, we got practice using the secondary key functionality of Berkeley DB. For the first task we added a secondary timestamp key, which is calculated when adding a new contact to the database. Once we implemented the secondary key, we added functionality for get-timestamp which allows a user to request a contact by their timestamp, and get-range which allows users to request a group of contacts by supplying a range of timestamps. For the second task, we designed a system that consists of three parts: a Wicket web application client, a Restlet based server, and a persistent/embedded database using Berkeley DB. The Wicket webpage is a web based client which allows users to add and retrieve contacts by interfacing with the Restlet based server. The server, in turn, communicates with and performs actions on our embedded Berkeley database.
Berkeley Database Katas
These katas were pretty similar to the previous Restlet katas we did. These Berkeley DB katas actually used a combination of skills we learned while doing the first two sets of katas. We combined the Wicket web application from the first set of Katas, and the idea of a database from the second set of katas. The only difference was that the database used in these exercises was a persistent database while the one used in the previous assignment was not.
-
Kata 1: For this Kata, you will first implement a secondary key for Contacts that consists of a timestamp represented as a long value. Also implement get-timestamp and get-range functions for client use. Get-timestamp should allow the user to request a contact by its timestamp and get-range should return a group of contacts given a range of timestamps.
Completed: Yes
Time Spent: 1 hour 45 minutes
Summary: This was fairly easy, it just required looking a the Berkeley DB API and examining the pre-existing code for the primary key in our system. Adding and calculating the timestamp was pretty straight-forward, I would say that the most difficult part was adding the get-range functionality, but when looking through the API I was able to find a section on grabbing ranges of keys. Writing the unit test probably took equally as long as completing the task. -
Kata 2: Create a client-server system for managing contacts that
Provides a Wicket client which consist of a single page, and allows the user to store a contact given its info, and retrieve a contact given its unique ID. The Wicket client code should invoke an underlying Restlet-based module to send a request to a ContactDB server to put or get data.
The system should aslo provide a Restlet and BerkeleyDB server. The server should accept and process requests using Restlet, and use BerkeleyDB to persist the Contacts.
Completed: Yes
Time Spent: 5 hours 20 minutes
Summary: The hardest part of this for me was probably conceptualizing how everything would interact with each other. After about an hour of studying how the pieces would fit together I was able to get started, and everything went pretty smooth for the most part. The only issue I ran into was trying to fix a bug with adding contacts through the Wicket web interface. I kept looking over the code thinking that everything should be working, and I couldn't figure out why it wasn't. Eventually I realized that I was passing the parameters, to create an instance of a Contact object, in the incorrect order. I guess it was just another lesson learned though. If you pay attention and do things carefully the first time, you can save yourself hours on trying to fix minor bugs.
Another issue I ran into was having a static field in my WicketWebApp class. PMD was giving me an error saying that that the class had static variables which was unsafe. I believe it was unsafe because the variables were shared by all users accessing the web application. I solved the issue by adding sessions to the Wicket application. By adding sessions, multiple users can now access the web app which modifies one universal database.
No comments:
Post a Comment