Code distribution. The code for the Page File component, and the interfaces and skeleton files for the Record Manager component, are given to you in your team's subversion repository. See the main project page for details on how to access your repository. Filenames that begin with "Record" form a skeleton version of the Record Manager component implementation that you must flesh out (see interfaces below). The other source and header files form the Page File component. We have used a Java-style convention for file names, where the file name is the same as the class name, so it should be easy for you to guess which file does what. A few of the files, such as AllocationPage.cpp, correspond to classes used internally by the Page File components, and can be ignored. The distribution also contains a file Test.cpp that contains some sample tests.
cmake. We will use cmake to generate a Linux makefile to compile your code. cmake is installed on the CSIF lab machines (and is a free download for use at home). The code distribution includes a cmake makefile called CMakeLists.txt. When adding new source files and headers to your project, please make sure to keep this file updated. To generate a Linux makefile, simply run "cmake ." from the command line. cmake can generate a number of different makefile and project formats, such as Eclipse projects, as well; see the online documentation for details.
Subversion. Team members will coordinate their efforts, and submit their code, via a dedicated subversion repository for that team. See the main project page for details.
Directory structure. Some teams may feel moved to introduce a nested directory structure to their codebase, e.g., to keep the source files for separate components in their own sub-directories. However, please do not do this! (Even if you feel good engineering practice dictates otherwise :) Our automated tests assume that all source files and headers are in the same directory.
Submission and building. When submitting your code, you need to make sure that it also builds from the command line on the CSIF machines. You will not receive any credit if your submission does not build! It's recommended that you perform your project submission from the CSIF machines; as a sanity check, the submission script, submit.sh, will automatically launch a test build after submitting your code and will warn you if the build fails.
Before you begin coding, please answer the first question in the text file, which asks you to estimate the total number of person-hours you think will be needed to implement your solution (including testing).
Before submitting your code using submit.sh, please answer the the second question, which asks how many person-hours of effort were actually required.The purpose of these questions is to give you some practice at the
difficult task of software project estimation, to force you to think
a little bit about your design and testing strategies before you
plunge into implementation, and to gather useful information about
the effort required for this class that we will use to tune the
difficulty of assignments in subsequent years.
Guidelines and Suggestions
As mentioned already, you must not modify the public methods of the
classes that we have provided (although you may add new public
methods). Beyond this basic requirement, there is a fair bit of
leeway in how to actually carry out the implementation. Below are
some suggestions.
File and page layout. Each record file will likely need one or more header pages, on which you store information about the file as a whole, followed by a collection of data pages. Each data page will likely also contain some header information in addition to records.
File header management. Your implementation of RecordManager::openFile will call PageFileManager::openFile to actually open the file. You will probably also want to read some header information at that time, containing information such as record size and the number of pages in the file, and copy it into your RecordFileHandle object as class data. Once you have read the header information, you can unpin the header page to free its block in the buffer pool. If changes are made later to the header information, it must be eventually written back to the file when the file is closed.
Record identifiers. The RecordID class defines unique identifiers for records within a given file. Record identifiers will serve as tuple identifiers for higher-level DavisDB components. Thus, the identifier for a given record should be permanent, and should not change if the record is updated, or when other records are inserted or deleted.
Keeping track of free space. When inserting records, you are strongly discouraged from performing a linear space through pages in order to find a page with free space. Rather, you should adopt an approach like one of those described in lecture. You should also take care to avoid placing a limit on the total number of records that can be stored in a file: each file should be allowed to grow arbitrarily large. (Of course, there is an implicit limit given by the range of the int data type used for record and page numbers, but it should be possible to change this type - say, to a long - without otherwise changing your code.)
Details about obtaining the code distribution, using your team's subversion repository, and submitting your code are on the main project page.