Berkeley DB Katas

After learning the REST for the last couple of weeks, we are now tackling the database persistency with the use of an open source called Berkeley DB. The last couple of Kata's that we did, data was temporarily stored in the program and then deleted after the program finished running. This week, we are learning database persistency, which stores the data permanently somewhere in the program just like a real database. Below are the Katas that we needed to do to get familiar with persistency.

TO DO: Kata 1: Timestamp as secondary index

The example system provides a single key for retrieval of a Contact: it's unique ID. For this Kata, we will first implement a secondary key for Contacts that consists of a timestamp represented as a long value. For example, (new Date()).getValue() returns the current time as a long value.  This timestamp could mean a variety of things in practice, such as the time the contact was created, or the contact's birthday, etc., but we won't worry about that for now. 

Write unit tests to make sure that your secondary index works correctly, and that in particular you can retrieve a set of Contacts whose timestamps fall within a specified range.  

Once implemented, extend the ContactClient system with two new commands:

• get-timestamp: returns the Contact with the given timestamp, if such a Contact exists.
• get-range: returns the set of Contacts with timestamps between two specified values. 

Note that all of the sensor data in the Solar Decathlon system will have timestamps associated with them, and a frequent operation on the database will be to retrieve the sensor data instances during a given time period, so this kata will help you understand how to do that.

RESULT: This Kata was very confusing at first specifically the relation that we need to use for the secondary index. We decided to chose ONE_TO_ONE. It took us about half an hour to decide on this. We first tried to use ONE_TO_MANY but it needs an array or collection to hold the key. This made the addition of secondary key a lot harder. Since I don't any experience with databases,  I over think this simple problem and cost me to consume more time finishing this Kata. It took me more than 2 hours to finish this Kata.

TO DO: Kata 2: Wicket, REST, and BerkeleyDB

Create a client-server system for managing contacts that:

1. Provides a Wicket client.  The wicket client should consist of a single page, and allow 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.
2. Provides a Restlet and BerkeleyDB server.  The server should accept and process requests using Restlet, and use BerkeleyDB to persist the Contacts.

Below is the diagram on how we suppose to accomplish this task.

RESULT: This Kata as expected is the hardest. This pretty much the combination of what we learned so far from the last semester to this current one. This is also the introduction on what we're going to be working on for the rest of the semester- the Home Management System for the Team Hawaii's house. Each system that we learned so far will be part of the web-based services:  user interface (Wicket), communication (Restlet), and persistent storage (BerkeleyDB). The way I looked at this Kata is in a more familiar way: Wicket is HTML, Restlet is PHP and Berkeley DB is SQL. The idea is similar where HTML display the UI and uses PHP to communicate to the SQL database, but the implementation are way different and a requires a lot more work. There are a lot of stuff going on on this Kata. I adapted the Wicket web interface from the REST I Kata, making sure that all necessary API's and programs were downloaded. We were also warned that we needed to use session for this Kata which made it a lot harder because we have to read and research to make this work. This Kata cost me about a day (8 hrs) and lots of research and head bumping on the table.

Download: Berkeley DB Katas