Please report any errors directly to Josh: hug@cs.berkeley.edu

Pre-lab

• git pull skeleton master
• Watch the project 2 getting started video, available here.
• Read the project 2 partnerships guide.
• Optionally, read over the project 2 spec.
• Understand that project 2 will be a marathon and not a sprint.

Introduction

In this lab, you will learn about project 2, and will ideally find a team of 4 people with whom you can work throughout project 2. The project 2 timeline is as follows:

• Lab 2/16 and 2/17: Work alone or with a group to familiarize yourself with the spec.
• Saturday 2/18: Register your design group. Spend the next week coming up with a design.
• Lab 2/23 and 2/24: In-lab design reviews. Everyone from the design group must be able to find a lab that they can all attend.
• After 2/24: Design group splits into two independent implementation groups. Project is due.

We recommend that you form groups of similar programming skill. You'll get more out of working with someone at your speed. I strongly encourage faster groups to attempt the difficult optional challenges, especially parsing. Although it does not earn you extra credit, it might intrigue you. See the spec for details.

You may do this lab either alone or as part of a 2-4 person team. However, project 2 must be done in a group! If you need to work alone for some reason, please fill out the solo project 2 petition.

If you have not found a ground by the end of the lab, let your lab TA know and they will have you fill out a partner matching form.

Part I: Getting Acquainted

We've provided a staff solution to project 2, which can only be accessed from your instructional accounts. To run it, login in to your instructional account. If you forgot your password, you can reset it using this link. Once there, use the staffProj2 command, and you should find yourself here:

STAFF SOLUTION
CS61B Spring 2017: Project 2, Database
Even though it passes all the autograder tests, the
staff solution is likely not perfect, it may contain
bugs. If you believe you have found one, please make a
private post on Piazza and the staff will investigate.
>

For this lab, you'll want to understand the join operation. Start by creating a table called T1 that contains the values below:

T1

To do this in the staff solution, use the following commands.

> create table T1 (x int, y int)
> insert into T1 values 2, 5 
> insert into T1 values 8, 3
> insert into T1 values 13, 7
> print T1
x int,y int
2,5
8,3
13,7
> exit

Now try to create a table using the load command. Do this, create a file called T1.tbl, and inside of it put exactly:

x int,y int
2,5
8,3
13,7

Now start up project 2 again, and you should be able to print out the table.

> load T1
> print T1

Exercise 1: Give T3, the results of joining tables T1 and T2. To join two tables, we simply use the select command as follows:

> select * from T1, T2

T1

T2

T3

Exercise 2: Give T6, the result of joining tables T4 and T5.

T4

T5

T6

Exercise 3: Give the result of joining tables T7 and T8.

T7

T8

T9

Exercise 4: How many rows will be in the table that results from joining T10 and T11?

T10

T11

Exercise 5: How many rows will be in the table that results from joining T12 and T13?

T12

T13

Part II: Prototyping and Design

In 61B, the heart of your design is:

1. Your choice of classes.
2. Your choice of data structures, i.e. instance variables in each class.

The most important part of your design for this project is how you'll store your tables. For example, for this project, one design might have a Table class, a Row class, and a Column class, where the Table has a List<Row> and a List<Column> and each Row and each Column has its own instance variables.

Another simpler design might use a Table class only, which stores everything in a String[][].

This choice will affect EVERYTHING you do for the entire project, and the difference between good data structures and bad ones will dramatically affect not only the performance of your code, but also how hard it is to implement and test your design.

Since this is your first design project, we will not provide performance requirements, except that your code should be "reasonable", meaning that your code should not take exponentially long to run as a function of input size. See the spec for more details. Luckily, we're pretty sure that ANY choice of classes/data structures will allow a reasonable solution, so you shouldn't worry about performance in your design.

However, you should ensure that your design lends itself to an easy implementation. A good choice of data structures may reduce the amount of time your project takes by a factor of perhaps 5.

In previous semesters of 61B, we've found that some students do something like this:

1. Come up with an initial design.
2. Implement the easy operations.
3. Move on to implementing the hard operations, and realize design results in a very hard implementation.
4. Create a new design that you think will handle the hard case.
5. Implement easy parts of project to match new design. This takes a long time because the student doesn't have unit tests.
6. Move on to implementing the hard operations. Possibly go back to step 3.

To help you avoid this painful workflow, we'd like you to start your design process by considering the hardest operation first, namely "join". Before we get there, though, there is the matter of creating a basic table representation.

Exploratory Programming

Often it's hard to tell exactly what you'll need until you start implementing. Especially for novice programmers, designing without writing any code can be very hard.

To get a better handle on this project, spend the rest of this lab creating a Table class, which includes:

• A constructor.
• An addRow method.
• A main method that creates table T1 from this lab using the constructor and addRow methods.

There is no specific API for this task. That is, you can use whatever signatures you want for the constructor and addRow methods. Pick any instance variables that you think will allow you to achieve those objectives.

It's OK to assume that all types are int for now.

Some recommendations: Your constructor should not take a collection of rows. The number and names of the columsn should be immutable (See 2/15 lecture for a definition of immutability).

This table class will not be graded.

Submission and Check-in

Submit Lab5.java. This time you don't need to do anything. Make sure your TA records your attendance before leaving lab. If you do not have a design group by the end of lab and you'd like your lab TA to help you find a group, let your TA know and they'll send you a form for matching you with a group.

Between Now and Lab 6

By Saturday night, register your group using this form.

Between now and lab 6, try to come up with a design for our project, particularly one that will make your join method less painful. You may need to try a few different designs (e.g. a few different ideas for instance variables).

Work with your group to come up with a design for the project. This will involve a lot of reading of the spec, and also some prototyping.

Ideally, before next lab, you'll have written a join method which at least partially works, as well as tests for that method. You may share the following code with any member of your design group:

1. A table constructor and instance variables.
2. Code for joining exactly two tables.
3. Tests of any of the above.

If you get more done before next week, do not share code that goes beyond the above three things with the other ICT in your design group.

You'll also have HW1 due 2/22, so make sure to allocate enough time to do that as well. After HW1 is in, the only work for this class will be this project until 3/6.