Lab 1

godb/buffer_pool.go

@@ -20,7 +20,6 @@ const (
 type BufferPool struct {
 	// TODO: some code goes here
 	pages    map[any]Page
-	keyOrder []any
 	numPages int
 	currPage int
 }
@@ -29,7 +28,6 @@ type BufferPool struct {
 func NewBufferPool(numPages int) (*BufferPool, error) {
 	return &BufferPool{
 		pages:    make(map[any]Page),
-		keyOrder: []any{},
 		numPages: numPages,
 		currPage: 0,
 	}, nil
@@ -46,7 +44,6 @@ func (bp *BufferPool) FlushAllPages() {
 		page.setDirty(0, false)
 	}
 	bp.pages = make(map[any]Page)
-	bp.keyOrder = []any{}
 	bp.currPage = 0
 }
 
@@ -108,9 +105,8 @@ 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 i, pageKey := range bp.keyOrder {
-			if !bp.pages[pageKey].isDirty() {
-				bp.keyOrder = append(bp.keyOrder[:i], bp.keyOrder[i+1:]...)
+		for _, page := range bp.pages {
+			if !page.isDirty() {
 				bp.currPage--
 				break
 			}
@@ -120,7 +116,6 @@ 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-valkwek.txt

@@ -0,0 +1,34 @@
+Collaborator: Victoria Gao
+
+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), 
+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 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), numSlots (max slots for the page), and emptySlots (slots that can be used for inserting a new tuple). 
+To delete a tuple, we change the tuples list to have nil where the tuple originally was. To insert a tuple, we 
+insert it at emptySlots[len(emptySlots) - 1] and update emptySlots to show that a tuple is now at that index. 
+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, td (tuple descriptor), and 
+numPages. 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, as well as increment numPages. 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. 
+We spent 20 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! 

godb/lab1-writeup-vgao.txt

@@ -0,0 +1,33 @@
+Collaborators: Valerie Kwek
+
+Design decisions:
+
+One design decision we made was storing the slot number of empty slots for each page in an array that's an 
+attribute of HeapPage. When we insert a new tuple, we insert it into the slot number at the end of empty slots
+array so that we just have to pop last element from empty slots array. When deleting a tuple, we add the 
+slot number in the tuple's Rid back to the empty slots array.
+
+In buffer pool, the BufferPool struct has the following attributes:
+- pages: map each page key (outputted by heap_file's pageKey function) to a 
+Page (implemented by heapPage struct)
+- numPages: maximum number of pages we can store in the buffer
+- currPage: number of pages that are currently in the buffer
+
+For heap_page, we maintained the number of used slots in numUsed int attribute of heapPage struct, 
+which we incremented when we added a new tuple and decremented when we deleted a tuple. 
+We store a page's tuples in an array and delete a tuple by setting an index of the page's tuples array to nil.
+When we insert a new tuple in a page, we iterate from the beginning (index = 0) to the end 
+(index = page.numSlots, exclusive) of the page's tuples array and put the tuple in the 
+first empty slot (i.e., tuples[<index>] = nil).
+For serializing and deserializing heap page, we store numSlots, numUsed, and tuples in the buffer as suggested
+in the instructions.
+
+For heap files, we maintained the number of pages currently in heap file in HeapFile struct's numPages attribute.
+
+Changes to API: not much; we just added attributes to structs and didn't change interface definitions in types.go
+
+Missing/incomplete parts of code:
+- In buffer pool, we haven't implemented AbortTransaction, CommitTransaction, nor BeginTransaction nor dealt
+with locking.
+
+Time Spent on the lab: 20+ hrs