Parts 1-4

godb/buffer_pool.go

@@ -20,6 +20,7 @@ const (
 type BufferPool struct {
 	// TODO: some code goes here
 	pages    map[any]Page
+	keyOrder []any
 	numPages int
 	currPage int
 }
@@ -28,6 +29,7 @@ type BufferPool struct {
 func NewBufferPool(numPages int) (*BufferPool, error) {
 	return &BufferPool{
 		pages:    make(map[any]Page),
+		keyOrder: []any{},
 		numPages: numPages,
 		currPage: 0,
 	}, nil
@@ -44,6 +46,7 @@ func (bp *BufferPool) FlushAllPages() {
 		page.setDirty(0, false)
 	}
 	bp.pages = make(map[any]Page)
+	bp.keyOrder = []any{}
 	bp.currPage = 0
 }
 
@@ -105,8 +108,9 @@ func (bp *BufferPool) GetPage(file DBFile, pageNo int, tid TransactionID, perm R
 		return nil, fmt.Errorf("could not read page")
 	}
 	if bp.currPage == bp.numPages {
-		for _, page := range bp.pages {
-			if !page.isDirty() {
+		for i, pageKey := range bp.keyOrder {
+			if !bp.pages[pageKey].isDirty() {
+				bp.keyOrder = append(bp.keyOrder[:i], bp.keyOrder[i+1:]...)
 				bp.currPage--
 				break
 			}
@@ -116,6 +120,7 @@ func (bp *BufferPool) GetPage(file DBFile, pageNo int, tid TransactionID, perm R
 		}
 	}
 	bp.pages[pageKey] = page
+	bp.keyOrder = append(bp.keyOrder, file.(*HeapFile).pageKey(pageNo))
 	bp.currPage++
 	return page, nil
 }

godb/lab1-writeup.txt

@@ -0,0 +1,36 @@
+Describe any design decisions you made. These may be minimal for Lab 1.
+Discuss and justify any changes you made to the API.
+Describe any missing or incomplete elements of your code.
+Describe how long you spent on the lab, and whether there was anything you found particularly difficult or confusing.
+
+For design decisions, we made minimal changes and mostly went off of the structs described in the bootcamp. 
+
+In tuple.go, we made a heapRecordID implementation of the recordID interface to keep track of the page number and 
+slot number. 
+
+In buffer_pool.go, we made a BufferPool struct made up of pages (that maps page keys to their pages), keyOrder (to 
+keep track of the order in which pages were put into the buffer for eviction purposes), numPages (representing the 
+max number of pages we can keep in the buffer), and currPage (representing the current number of pages in the buffer). 
+Flushing all pages clears the pages map, clears the keyOrder, and sets currPage to 0 as there are now no pages in the 
+buffer. To get a page, we first check if it is in the buffer. If it is not and the buffer is full, we iterate through 
+the pages to see which page to evict; we evict the first page that is not dirty. After, we add the new page to the 
+buffer. This includes updating the pages map and key order, as well as incrementing the currPage counter. 
+
+In heap_page.go, we made a HeapPage struct made up of Desc (tuple descriptor), PageNo, HeapF (for the heap file it 
+is part of), tuples (list of tuples on the page), IsDirty (whether it's been modified or not), numUsed (slots used 
+for the page), and numSlots (max slots for the page). To delete a tuple, we change the tuples list to have nil where 
+the tuple originally was. To insert a tuple, we iterate through the tuples list to look for an empty nil slot. 
+Serializing and deserializing consists of reading tuples to and from the buffer a total of numUsed times to read in 
+all of the tuples. 
+
+In heap_file.go, we made a HeapFile struct made up of bufPool (buffer pool), backingFile, and td (tuple descriptor). 
+To read a page, we read at the offset pageNo*PageSize from the backing file. To insert a tuple, we first try to add 
+it to one of the pages in the heap file; if this doesn't work, we need to create a new page and add it there. To 
+delete a tuple, we go to the page number it is located in, and call the deleteTuple method from that page. Flushing 
+a page writes it back to the backing file. The iterator method goes through each page and continuously iterates 
+through every tuple on the page to return it. Finally, we use the pageKey (consisting of the file name and page 
+number), in the BufferPool struct. 
+
+So far, we're passing all the test cases; however, we're missing the TID concurrencies implementation for future 
+labs. We spent 15 hours on this lab; we found understanding the pseudocode to be a bit confusing, and debugging in 
+Go has not been that intuitive. It'd be helpful to maybe include more office hours!