All problems due by 11:59 p.m. on Tuesday, November 5, 2024.
In your work on this assignment, make sure to abide by the collaboration policies of the course.
If you have questions, please come to office hours, post them on
Piazza, or email cs460-staff@cs.bu.edu.
Make sure to submit your work on Gradescope, following the procedures found at the end of Part I and Part II.
45 points total
Create a subfolder called ps3 within your
cs460 folder, and put all of the files for this assignment in that
folder.
This part of the assignment will all be completed in a single PDF file. To create it, you should do the following:
Access the template that we have created by clicking on this link and signing into your Google account as needed.
When asked, click on the Make a copy button, which will save a copy of the template file to your Google Drive.
Select File->Rename, and change the name of the file to
ps3_partI.
Add your work for the problems from Part I to this file.
Once you have completed all of these problems, choose
File->Download->PDF document, and save the PDF file in your ps3
folder. The resulting PDF file (ps3_partI.pdf) is the one that
you will submit. See the submission guidelines at the end of Part I.
18 points total
Below are two schedules in which actions by three transactions (T1, T2, and T3) are interleaved.
schedule 1:
w1(A); r3(A); w2(C); r2(B); c2; r1(C); c1; w3(B); c3
schedule 2:
r1(C); w2(B); w1(A); w2(C); c2; r3(B); w3(B); c3; r1(B); c1
For each of the above schedules, you should take the following steps:
In your copy of the ps3_partI template (see above), edit the
diagram that we have provided for the schedule, making whatever
changes are needed to construct the schedule’s precedence graph.
State whether the schedule is conflict serializable. Explain briefly why or why not. In addition, if the schedule is conflict serializable, state one possible equivalent serial schedule.
State whether the schedule is recoverable. Explain briefly why or why not.
State whether the schedule is cascadeless. Explain briefly why or why not.
8 points total
Consider these two transactions:
T1: r(A); r(B); r(C); w(C); commit T2: r(B); r(A); r(C); w(A); commit
The following is the beginning of one possible schedule of these transactions, with appropriate lock instructions added:
|
T1 |
T2 |
|---|---|
|
sl(A); r(A) |
|
Given the remainder of the schedule, if the system is using regular two-phase locking (not strict or rigorous), could T2’s next action be to unlock B? Explain briefly why or why not.
Regardless of your answer to part 1, imagine that T1 actually goes next and completes two more actions:
|
T1 |
T2 |
|---|---|
|
sl(A); r(A) |
|
Fill in the table that we have provided in ps3_partI to show one
way in which this partial schedule could be successfully completed
under strict two-phase locking. There is more than one possible
answer to this question.
Important guidelines:
The actions that you add should go below the dotted lines in the table. Make sure to position them so that there is no confusion about the order in which they occur.
Make sure to include appropriate lock, unlock and commit actions. You should assume that the DBMS is not using update locks, and that it allows shared locks to be upgraded to exclusive locks.
To show that you understand the difference between strict and rigorous locking, at least one of the unlock actions should come before the commit action of the corresponding transaction.
9 points total; 1.5 points each part
Consider the following partial schedule of the transactions T1, T2, and T3:
xl2(A); w2(A); sl1(B); r1(B); ul3(C); ...
Given this partial schedule, which of the following lock requests would be granted if it were the next operation in the schedule, and which would be denied?
xl2(B)sl3(B)sl1(C)ul2(B)xl3(C)ul1(C)Fill in the provided table with the system’s response to each request,
along with a brief explanation of your answer. (Remember: uli(X)
indicates Ti’s request of the update lock for X.)
10 points total
Consider the following sequences of operations by concurrent transactions:
sequence 1:
w3(A); r2(A); w2(A); r1(B); r3(B); w3(B); w1(C)
sequence 2:
r2(C); r1(D); w1(C); r3(C); w2(C); w3(D); w1(D)
For each of these sequences, determine whether deadlock will occur under rigorous two-phase locking. You should assume that:
If deadlock occurs, show the partial schedule in table form (including lock and unlock operations, and any commits) up to the point of deadlock, along with the waits-for graph at the point of deadlock.
If deadlock does not occur, show the full schedule, including lock and unlock operations and commits. In that case, you do not need to include the waits-for graph.
If a transaction needs to wait for a lock:
You should show the lock request, followed by a note that indicates the need to wait (e.g., “waits for T1”).
While the transaction is waiting, you should skip any of its actions in the schedule. That’s because a waiting transaction cannot make any forward progress until the lock that it is waiting for is granted.
If the lock request is subsequently granted, you should show the lock request again at the point at which it is granted. Then you can continue with the rest of that transaction’s actions from the schedule. Note that waits may cause the actual sequence of operations to be different than the original sequence.
If two transactions wait for a lock held by the same other transaction, and that other transaction subsequently commits, you should assume that the waiting transaction with the smaller transaction number is granted its request first.
Login to Gradescope by clicking the link in the left-hand navigation bar. Once you are in logged in, click on the box for CS 460.
Submit your ps3_partI.pdf file using these steps:
If you still need to create a PDF file, open your file
on Google Drive, choose File->Download->PDF document, and
save the PDF file in your ps3 folder.
Click on PS 3: Part I in the list of assignments on Gradescope. You should see a pop-up window labeled Submit Assignment. (If you don’t see it, click the Submit or Resubmit button at the bottom of the page.)
Choose the Submit PDF option, and then click the Select PDF
button and find the ps1_partI.pdf that you created in step 1.
Then click the Upload PDF button.
You should see an outline of the problems along with thumbnails of the pages from your uploaded PDF. For each problem in the outline:
As you do so, click on the magnifying glass icon for each page and doublecheck that the pages that you see contain the work that you want us to grade.
Once you have assigned pages to all of the problems in the question outline, click the Submit button in the lower-right corner of the window.
You should see a box saying that your submission was successful.
Click the (x) button to close that box.
You can use the Resubmit button at the bottom of the page to resubmit your work as many times as needed before the final deadline.
Important
It is your responsibility to ensure that the correct version of a file is on Gradescope before the final deadline. We will not accept any file after the submission window for a given assignment has closed, so please check your submission carefully using the steps outlined above.
If you are unable to access Gradescope and there is enough
time to do so, wait an hour or two and then try again. If you
are unable to submit and it is close to the deadline, email
your homework before the deadline to
cs460-staff@cs.bu.edu
55 points total
All of Part II is pair-optional, which means that you may complete it with a partner. See the rules for working with a partner on pair-optional problems for details about how this type of collaboration must be structured.
In this assignment, you will implement portions of a simple relational database management system that supports a subset of the SQL language. We have provided you with two of the three components of the system:
Your job is to implement parts of the “middle layer” of the system, which takes the parsed version of a SQL command and performs the necessary lower-level actions to execute the command. To help you, we have given you a code framework for the middle layer that already provides some of the necessary functionality.
You should begin by downloading the necessary files and configuring your work environment. The steps for doing so can be found here.
Please do this ASAP, so that you can be sure that you don’t run into any problems later on.
After configuring everything, you should spend some time
familiarizing yourself with the files that we have given you in the
dbms folder, and with Berkeley DB. In particular, you should
review/read the following resources:
The following additional resources may also be helpful:
highly recommended
Before you begin coding, we strongly encourage you to answer the questions found here:
code-reading and design questions
In the code that you write, you must limit yourself to the packages that we’ve imported at the top of the starter files. You must not use classes from any other Java package. In addition, you must not use any Java features that were not present in Java 8.
As discussed on the separate configuration page, you will need to compile and run the code from the command line in the Terminal window of VS Code.
to compile:
javac -cp 'lib/*' -d classes *.java
(see below for the expected warning messages)
to run on Windows:
java -cp 'lib/*;classes' DBMS
to run on macOS:
java -cp 'lib/*:classes' DBMS
Note: The two commands for running the program are almost
identical, but in the Windows version there is a semi-colon (;)
before the word classes, whereas the macOS version uses a
colon (:).
You will see one or more warnings when compiling your code (e.g., “Note: Parser.java uses unchecked or unsafe operations.”). These warnings are to be expected and should be ignored. Messages labeled as errors (not warnings) will keep your code from compiling and will need to be addressed. You shouldn’t see any errors when you compile the starter code that we’ve given you. If you do, let us know.
After making changes to the code, you will need to recompile it before you can try to re-run it. When you are at the command line of the Terminal, using the up arrow will allow you to access and reenter previously entered commands without needing to re-type them!
The code that we’ve given you can be run before you make any changes. It will begin by printing the following prompt:
Enter command (q to quit):
If you enter a valid SQL command, the program will parse the command
and display a summary of some of the command’s components (see the
notes on the DEBUG constant below for how to disable this summary).
Entering a lower-case q will allow you to quit the program.
When you run the program for the first time, it will create a
directory called db within your code directory. This is the home
directory for the Berkeley DB environment, and it will be used to
store the files that BDB creates for your database. If your program
crashes for any reason, these files may be corrupted. As a result,
we recommend that you remove all files from this directory after
a crash.
There is a constant named DEBUG that is defined in DBMS.java. When
it is set to true (as it is in the files that we have given you),
the values of many of the tokens generated by the parser are printed
after each SQL command is entered by the user. You may find this
information helpful as you implement the various types of commands.
You may also wish to add additional debugging code that is only
executed when this constant is set to true. To eliminate the
debugging messages, set DEBUG to false.
20 points
Important
Before you begin coding, make sure that you have completed the tasks listed under the Getting Started section above, and that you have answered the code-reading and design questions mentioned above.
In order to insert rows into a table, your DBMS needs to be able to
marshall a collection of column values into a single Berkeley DB
key/value pair. In this problem, you will add support for marshalling
by implementing the key method of the InsertRow class.
As you saw when completing the code-reading
questions, an InsertRow object is used by
the execute() method for INSERT commands (the one in the
InsertStatement class). That execute() method creates an
InsertRow object to represent the row to be inserted, and it calls
that object’s marshall() method to prepare the marshalled
key/value pair for the row.
We have already implemented some of the other methods of this class for you:
InsertRow constructor that initializes the state of object.
It takes two parameters: an already opened Table object for
the table to which the row will be added, and an array of type
Object containing the values in the row to be inserted. We
assume that the values are in the appropriate order – i.e.,
that element 0 of the array contains a value for the first
column in the table, element 1 contains a value for for the
second column in the table, etc. We also assume that the values
are valid and that they have been adjusted as needed to
correspond to the types of the columns.getKeyBuffer() method that returns a RowOutput object for
the key portion of the marshalled key/value pair.getValueBuffer() method that returns a RowOutput object for
the value portion of the marshalled key/value pair.toString() method that returns a String representation
that includes:offsets field, which we
recommend that you use when determining the offset values
that will appear at the start of the marshalled valueRowOutput for the key)RowOutput for the value).
This toString() method should help you when debugging your
marshalling code.You will implement the marshall() method, which should take the
column values of the InsertRow object and marshall them into byte arrays
for the key/value pair that will eventually be inserted into the
B+tree for the table.
Important: marshall() should not interact with Berkeley DB at
all. In particular, it should not create any DatabaseEntry
objects or attempt to add them to the BDB database.
Rather, marshall() should only do the following:
Determine the correct offset values and store them in the
array to which the offsets field in the InsertRow object refers.
Write the appropriate values into the buffers represented by
the keyBuffer and valueBuffer fields, each of which refers to
a RowOutput object.
See below for more detail about each of these tasks.
Notes:
Each key/value pair should have the format that we discussed in the lecture notes on the logical-to-physical mapping. The key portion of the key/value pair should be based on the value of the primary-key column. The value portion should consist of a header of offsets followed by the values of the non-primary-key, non-null columns.
The key portion of the key/value pair will be stored in the
RowOutput object assigned to the keyBuffer field of the
InsertRow object. The value portion will be stored in the
RowOutput object assigned to the valueBuffer field.
Because RowOutput objects fill their associated byte
arrays from left to right, you will need to determine all of
the offsets that belong in the header before you begin marshalling the
column values themselves. Store these offsets in the array to
which the InsertRow object’s offsets field refers.
Once all of the offsets have been computed and stored in
the offsets array, you can begin the process of writing into the
RowOutput objects using the appropriate methods.
The InsertRow constructor takes a reference to the
corresponding Table object as a parameter, and it stores that
reference in a field called table. Your code can obtain any
column information that it needs from the Table object and its
associated Column objects.
The getLength() method in a Column object gives the actual
length in bytes of all columns except VARCHARs. In the case of
VARCHARs, you should determine the length by invoking the
String.length() method on the actual value.
Because the column values are stored in an array of type Object,
you will need to use type casts in order to treat them as objects
of their actual types. For example, to treat values[i] as a
String, you would need to do something like (String)values[i].
Consult the Column class for the method you should use to determine
the type of a given column.
Integer values are stored in the values array as objects of
Java’s Integer class, and real values are stored as objects of
Java’s Double class. When marshalling these values, you will
need to convert them to primitive values of type int and
double, and you should use the Integer.intValue() and
Double.doubleValue() methods to do so. For example, if you have
an Integer object named val, you can convert it to an int by
making the method call val.intValue().
The RowOutput methods that you will use for writing the offsets
and column values are inherited from the DataOutputStream class,
so you should make sure to review the
API
of that class.
When marshalling a String value, you should use
the writeBytes() method, not the writeUTF() method.
You should assume that all offset values are small enough to be
represented by a two-byte integer, and thus you should use the
writeShort() method for them.
To keep the marshall() method from getting too large, you may
want to add one or more private helper methods that can be called
to do part of the overall task.
Important: If you write a helper method that uses one or
more of the RowOutput methods, you must include a throws
clause in the header of the method like the one we’ve given you
for the marshall method:
public void marshall() throws IOException {
Review the Table, Column, RowOutput, and
DataOutputStream classes as needed.
marshall() methodYou should test your marshall() method thoroughly before proceding to
the next problem.
We’ve given you the following tools for doing so:
The RowOutput class includes a toString() method that
shows the current contents of the underlying byte array.
The InsertRow class includes its own toString() method that shows
the current values in the InsertRow object’s offsets array and
the contents of the byte arrays underlying the RowOutput objects
assigned to its keyBuffer and valueBuffer fields.
The starter code that we’ve given you in the execute() method
of InsertStatement will create the necessary InsertRow object,
call your marshall() method, and – if the DEBUG constant in
the DBMS class is true – print the InsertRow object so that
you can examine the values of its fields. (Note that the row won’t
actually be inserted until you complete the execute() method as
part of Problem 4, but the existing code is sufficient for testing
the marshall() method.)
Given these tools, you can:
Compile and run the DBMS program as described above.
Create a table using a CREATE TABLE command. The starter code
already includes everything needed to carry out this type of command.
Enter one or more INSERT commands for the newly created table, and
see if the output from printing the InsertRow object looks correct.
For example, let’s say that you enter these two SQL commands:
CREATE TABLE Movie(id CHAR(7) PRIMARY KEY, name VARCHAR(64), runtime INT);
INSERT INTO Movie VALUES ('2294629', 'Frozen', 102);
If your marshall() command is working correctly, you should see the
following as part of the output of the debugging print statement:
for the offsets field:
[-2, 8, 14, 18]
Because there are three columns, there are four offsets. The -2
indicates that the first column (id) is the primary key.
The next two offsets (8 and 14) are the offets of the name
and runtime column values, and the 18 is the offset
of the end of the record.
for the key buffer (i.e., the keyBuffer field):
[50, 50, 57, 52, 54, 50, 57]
The numbers in this byte array represent the ASCII codes for
the characters in the id value '2294629': 50 for the
character '2', 57 for the character '9', etc.
for the value buffer (i.e., the valueBuffer field):
[-1, -2, 0, 8, 0, 14, 0, 18, 70, 114, 111, 122, 101, 110, 0, 0, 0, 102]
This byte array begins with 8 bytes for the offset table:
The first two bytes ([-1, -2]) represent the special -2
offset for the primary-key column. When -2 is represented
using a two-byte integer, the individual bytes
end up being the 8-bit representations of -1 and -2.
In general, when you use multiple bytes to store a
negative number whose absolute value is relatively small,
the rightmost byte will show the negative number itself,
and all of the remaining bytes will show -1. For example,
if we stored -3 using two bytes, we would see [-1, -3] as
its two bytes. If we stored -10 using four bytes, we
would see [-1, -1, -1, -10].
The next two bytes ([0, 8]) represent the offset of the
name column, which has an offset of 8 bytes because it
comes immediately after the offset table, which has a
length of 4*2 = 8 bytes.
The next two bytes ([0, 14]) represent the offset of the
runtime column, which has an offset of 8 + 6 = 14 bytes
in this particular row.
The next two bytes ([0, 18]) represent the offset of the
end of the record, which is 14 + 4 = 18 in this particular
row.
The next 6 bytes represent the ASCII codes for 'Frozen':
70 for 'F', 114 for 'r', etc.
The final 4 bytes ([0, 0, 0, 102]) represent the 4-byte
integer stored for the runtime value of 102.
Note: When you store larger integers, the resulting bytes can be harder to interpret. Here are some examples:
If you stored a runtime of 150 in the Movie table that we
created above, you would see the bytes [0, 0, 0, -106] for
the runtime. This stems from the fact that when only one byte
is used to store a signed integer (one that could be
negative), it can store any value between -128 and 127. When
we store 150 using two or more bytes, the 8 bits in the
rightmost byte look like they represent a negative number,
because 150 can’t actually be represented using an 8-bit signed
integer.
If you stored a runtime of 300, you would see the bytes
[0, 0, 1, 44] for the runtime. That’s because we need more
than 8 bits to store 300 as a binary number. In fact, when
we convert 300 to binary, we get a 9-bit number: 100101100.
When these 9 bits are stored as part of a 32-bit integer, we
get:
00000000 00000000 00000001 00101100
The bits in the rightmost byte represent the integer 44, and the bits in the byte to its left represent the integer 1.
Try inserting other rows as well, and convince yourself that your
marshall() method is working in all cases. For example, does it
work correctly when one of the column values is NULL?
INSERT commands7 points
We have given you the start of the execute() method of the
InsertStatement class, which is used to carry out INSERT commands.
As mentioned earlier, our provided code uses an InsertRow object
to prepare the row for insertion – marshalling it into a
key/value pair. You will need to complete the execute() method
by writing code that:
uses the byte arrays from the RowOutput objects in the
InsertRow object to construct the necessary Berkeley DB
objects for the key/value pair
adds the key/value pair to the underlying BDB database.
Notes:
The insertion should fail if there is already a key/value pair with
the specified key. You should choose the BDB insertion method that
will return a special value when the specified key already
exists. Your code should handle this return value by throwing an
exception with an appropriate error message. See our
CreateStatement code for examples of throwing an exception.
Note: The error message will be printed by the code that
we’ve provided in the catch block. You just need to create an
exception with the appropriate error message and throw the
exception. See our sample interaction below for what the error
message should look like.
If the insertion is successful, your code should print an appropriate message to indicate that fact. See our sample interaction below for what it should look like.
Review the Table and InsertRow classes as needed, as well as
the Berkeley DB Database class.
20 points
In order to execute a SELECT command, your DBMS needs to be able to
iterate over the rows in one or more tables, and to access the values
of the columns in those rows. In this problem, you will complete the
implementation of a table iterator that will be able to iterate over
all or some of the rows in a single table and access the values of the
columns. We can associate a WHERE clause with such an iterator, in
which case it will only visit rows that satisfy the WHERE clause.
Each table iterator will be an instance of the provided TableIterator
class. We have already implemented most of the methods of this class
for you, including:
a TableIterator constructor that takes an already opened table
object and initializes the state needed by the table iterator,
including:
DatabaseEntry objects called key
and value. These DatabaseEntry objects will be used
by the cursor methods to retrieve the current key/value pair.The constructor also examines the columns mentioned in the SQL
statement for which this iterator is needed, and it associates
this iterator with those columns; doing so allows the code that
evaluated the WHERE clause to use the iterator to obtain the
column values that it needs.
- a first() method that positions the iterator on the first
tuple of the table.
- a next() method that advances the iterator to the next tuple
specified by the SELECT command.
- a getColumn() method that takes an index nand returns a
Column object for the nth column in the table associated
with the iterator. The leftmost column has an index of 0.
- a close() method that closes the cursor associated with
the iterator.
- a printAll() method that will be called to iterate over all rows
in the associated table and print them out.
For this assignment, you should implement the method called
getColumnVal() that takes an index n and returns the value of the
nth column in the tuple on which the iterator is currently
positioned. To do so, it will need to unmarshall the appropriate value
from the BDB key/value pair associated with that tuple, and it should
use the metadata that you included when you marshalled the tuple to
efficiently access the value of the specified column. See the notes
below for more detail.
Notes:
We have already given you the code needed to handle the two types of exceptions that are mentioned in the comments before the method.
You code that you write should assume that the underlying cursor
has already been positioned on an appropriate key/value pair. The
key can be accessed using the DatabaseEntry object to which the
TableIterator‘s key field refers, and the value can be
accessed using the DatabaseEntry object to which the
TableIterator‘s value field refers.
Your code will need to use one or two RowInput objects to
unmarshall the value of the specified column.
For example, to create a RowInput object that is based on the
value portion of the current key/value pair, you would do something
like the following:
RowInput valIn = new RowInput(this.value.getData());
Your getColumnVal() method should not perform unnecessary
reads. Rather, it should only read (1) the offset or offsets
needed to determine where the column value is located and (when
necessary) the length of the column value, and (2) the column
value itself.
The RowInput class includes two methods for each type of value:
readIntAtOffset() and
readDoubleAtOffset()). These methods jump to the specified
position in the underlying byte array before performing the read.readNextInt() and readNextDouble()).
When the RowInput object is created, the
current offset is set to 0. After each read, the current
offset is updated to be the offset of the byte that comes
immediately after the value that was just read.The RowInput class also includes a toString() method that you
may find useful when debugging. It returns a string that includes
the contents of the underlying byte array and the current offset
within that array.
When unmarshalling the key portion of the key-value pair, you
can use the getSize() method in its DatabaseEntry object
to determine the key’s length in bytes.
Review the Table, Column, and RowInput classes as needed, as
well as the Berkeley DB DatabaseEntry class.
SELECT * for a single table8 points
Implement the execute() method of the SelectStatement class, and
any necessary helper methods. For this assignment, you will only
need to support SELECT * commands involving a single table.
Your method will need to open the table associated with the SELECT
command by using the open() method that we have provided for
Table objects. (See the start of the execute() method for
InsertStatement for an example of this.) The open() method will
get the table’s catalog metadata and add it to the Table object,
and it will also open the underlying BDB database if it isn’t
already open.
Your code should then create a TableIterator for the appropriate
table (assigning it to the variable iter that we have given you) and
invoke the printAll() method on it. This method, which we have
provided in TableIterator, will invoke the appropriate iterator
methods to obtain the table’s column values and display them with
appropriate formatting. Note that your SELECT-statement code does
not need to advance the iterator by calling next();
printAll() already does all of the iteration – and all of the other
work – for you, using the TableIterator method that you wrote.
Your execute() method should check for currently unsupported
SELECT commands:
FROM clauseSELECT clause.If either of those cases holds, you should throw an exception with an appropriate error message. See our sample interaction below for what these messages should look like.
In addition, your method should make sure that there is an existing
table with the given name; the open() method of the Table object
should make it easy to do so. When there is no existing
table with the specified name, you should create and throw an
exception with no error message, because code in the open() method
will already print the necessary error message.
If there are no errors, your method should finish by printing a message that includes the number of tuples selected. See our sample interaction below for what these messages should look like.
Notes:
When creating the TableIterator, make sure that you use the local
variable iter that we have declared for you at the top of the
method. Doing so will allow you to take advantage of the code
that we have given you at the end of the method, which closes the
iterator, and thus its underlying cursor.
The TableIterator constructor takes a reference to an object
of type SQLStatement. You should pass in a reference to the
SelectStatement object on which the execute method was
invoked, which you can do by using the implicit parameter
this. In addition, you should pass in true for the third
parameter of the constructor:
iter = new TableIterator(this, ..., true);
When you call the printAll() method, you should pass in
System.out as the parameter, so that the results will be
displayed on the console. (The reason that we make printAll()
take a parameter for this is for added flexibility. If we wanted
to, we could pass in a parameter that corresponds to a text
file, and the results would be written to that file instead of
to the console.)
Review the Table, TableIterator, and SQLStatement classes as
needed.
To give you a sense of what your DBMS’s output should look like, we
have provided a sample interaction below. Note: We set the
DEBUG constant to false in DBMS.java before we ran these
commands.
Enter command (q to quit): CREATE TABLE Course(name VARCHAR(20), enrollment INT);
Created table Course.
Enter command (q to quit): SELECT * FROM Course;
| name | enrollment |
---------------------------------------
Selected 0 tuples.
Enter command (q to quit): DROP TABLE Course;
Dropped table Course.
Enter command (q to quit): SELECT * FROM Course;
Course: no such table
Enter command (q to quit): CREATE TABLE Course(id CHAR(5) PRIMARY KEY, name VARCHAR(20));
Created table Course.
Enter command (q to quit): INSERT INTO Course VALUES ('01000', 'CS 460');
Added 1 row to Course.
Enter command (q to quit): INSERT INTO Course VALUES ('00050', 'Math 123');
Added 1 row to Course.
Enter command (q to quit): INSERT INTO Course VALUES ('02050', NULL);
Added 1 row to Course.
Enter command (q to quit): INSERT INTO Course VALUES ('00050', 'Physics 211');
There is an existing row with the specified primary key.
Could not insert row.
Enter command (q to quit): SELECT * FROM Course;
| id | name |
----------------------------------
| 00050 | Math 123 |
| 01000 | CS 460 |
| 02050 | null |
Selected 3 tuples.
Enter command (q to quit): SELECT name FROM Course;
Specifying column names in the SELECT clause is not supported.
Enter command (q to quit): CREATE TABLE Foo(id CHAR(5) PRIMARY KEY, year INT);
Created table Foo.
Enter command (q to quit): SELECT * FROM Course, Foo;
Specifying multiple table names in the FROM clause is not supported.
Enter command (q to quit): q
Login to Gradescope by clicking the link in the left-hand navigation bar, and click on the box for CS 460.
Important
Before submitting, you should find any print statements that
you added for debugging and either:
if statement that is based on the
value of the DBMS.DEBUG constant, as we did with
the debugging print statement that we gave you in
InsertStatement.java.You should submit only the following four files:
InsertRow.javaInsertStatement.javaTableIterator.javaSelectStatement.javaHere are the steps:
Click on PS 3: Part II in the list of assignments. You should see a pop-up window with a box labeled DRAG & DROP. (If you don’t see it, click the Submit or Resubmit button at the bottom of the page.)
Add your files to the box labeled DRAG & DROP. You can either drag and drop the files from their folder into the box, or you can click on the box itself and browse for the files.
Click the Upload button.
You should see a box saying that your submission was successful.
Click the (x) button to close that box.
The Autograder will perform some tests on your files. Once it is done, check the results to ensure that the tests were passed. If one or more of the tests did not pass, the name of that test will be in red, and there should be a message describing the failure. Based on those messages, make any necessary changes. Feel free to ask a staff member for help.
Note: You will not see a complete Autograder score when you submit. That is because additional tests will be run later, after the final deadline for the submission has passed. Passing all of the initial tests for a given problem does not necessarily mean that you will ultimately get full credit on the problem. You should always run your own tests to convince yourself that the logic of your solutions is correct.
If you worked with a partner and you are the one who is submitting the files:
Click on the Add Group Member link that appears below your name above the results of the Autograder.
In the pop-up box that appears, click on the Add Member link.
Type your partner’s name or choose it from the drop-down menu.
Click the Save button.
Check to ensure that your partner’s name now appears below your name above the results of the Autograder.
If needed, use the Resubmit button at the bottom of the page to resubmit your work. Important: Every time that you make a submission, you should submit all of the files for that Gradescope assignment, even if some of them have not changed since your last submission.
Near the top of the page, click on the box labeled Code. Then click on the name of each file to view its contents. Check to make sure that the files contain the code that you want us to grade.
Important
It is your responsibility to ensure that the correct version of a file is on Gradescope before the final deadline. We will not accept any file after the submission window for a given assignment has closed, so please check your submission carefully using the steps outlined above.
If you are unable to access Gradescope and there is enough
time to do so, wait an hour or two and then try again. If you
are unable to submit and it is close to the deadline, email
your homework before the deadline to
cs460-staff@cs.bu.edu
Last updated on October 30, 2024.