Chapter 6: Generating a software backend with Tabnine
The introduction connects the existing question database to the need for persistent test sessions that keep a test-taker’s questions available.
After this chapter you will be able to
- Persistent Test Session Purpose. Explain why the application assigns a question set to a persistent session: the test-taker should keep the same questions while moving through the test, even if the browser window closes accidentally.
- Question set constraint failure. Explain why loading the application again creates a session but fails when adding its questions.
- One ID for multiple questions. Explain why Tabnine’s first code change still violates the unique constraint.
- Database assigned question IDs. Describe the final insertion change and how the author checked that it worked.
- Button-triggered session creation. Explain how the index page changes from starting a session on page load to starting one when the user clicks a button: the form submits to the root route, which creates a question session for a POST request.
- Empty initial page handling. Describe how the application handles an ordinary GET of the index page before a session has started: it gives data an initial value and renders the question-list code only when data is populated.
- Cookie based session persistence. Describe the proposed way to retain a user's session if they accidentally close the browser.
- Uncreated session error. Explain why the attempted change fails on refresh and why the existing session-creation flow needs refactoring.
- Session creation on page load. Explain why session creation moves from a button-triggered POST into the index method, and how the page handles a missing versus an existing session ID.
- Session ID cookie response. Describe how the generated session ID is stored in a Flask cookie when a new session is created.
- Persistent ID changing questions. Distinguish keeping the same session ID from keeping the same question set, and explain the remaining problem seen on refresh.
- Session-based question set flow. Explain how the application should use a session ID stored in a cookie to choose between creating a new session and loading an existing session’s questions.
- Question set method refactoring. Describe why the current method produces new random questions on each visit and how passing it the session ID fixes that behavior. State what a browser refresh demonstrates after the change.
- End Session Button Behavior. Explain how the end-session button lets a user start over: it deletes the session cookie and refreshes the page, which displays a new session with new questions.
What it builds on
- Generating a question set (chapter 5) · The application has a generated question set to associate with a test session.
- Creating a test session in the database (chapter 5) · The application creates test sessions in the database.
Section by section
Introduction
The introduction connects the existing question database to the need for persistent test sessions that keep a test-taker’s questions available.
- Persistent Test Session Purpose: Explain why the application assigns a question set to a persistent session: the test-taker should keep the same questions while moving through the test, even if the browser window closes accidentally.
Why it matters: It explains what session management must preserve for a test-taker.
Key terms: session, question set, persist
6.1 Creating a session and our first bug
This section traces a duplicate-ID bug when creating question sets and shows how to test and refine Tabnine’s suggestions until new sessions work.
- Question set constraint failure: Explain why loading the application again creates a session but fails when adding its questions.
Why it matters: Separating the working session insert from the failing question inserts points debugging at the right table. - One ID for multiple questions: Explain why Tabnine’s first code change still violates the unique constraint.
Why it matters: A fix that succeeds for one row can still fail when the operation repeats. - Database assigned question IDs: Describe the final insertion change and how the author checked that it worked.
Why it matters: Letting the database assign each row’s ID avoids manually reusing one value across a question set. - Critical use of Tabnine suggestions: Explain how the author used Tabnine while checking its proposed fixes rather than accepting them at face value.
Why it matters: AI-generated code is more useful when you can see what it changes and test whether it fixes the actual bug.
Key terms: session_id, question_sets, question_set_id, unique constraint, create_question_set, None, null value, SQLite, auto-increment, Tabnine Chat
6.2 Creating an index page
The section turns session creation into a user-controlled button action and adjusts the route and template so the index page also loads before a session starts.
- Button-triggered session creation: Explain how the index page changes from starting a session on page load to starting one when the user clicks a button: the form submits to the root route, which creates a question session for a POST request.
Why it matters: A session should begin because the user asks for one, not merely because they open the page. - Empty initial page handling: Describe how the application handles an ordinary GET of the index page before a session has started: it gives data an initial value and renders the question-list code only when data is populated.
Why it matters: The page needs to load cleanly before the user has clicked the button or any questions exist to display. - Checking Tabnine suggestions: Explain why the author tests and corrects Tabnine's proposed changes rather than treating the initial suggestion as complete, using the missing Flask request import and undefined data as examples.
Why it matters: Testing an AI suggestion exposes integration mistakes before they become part of the working application.
Key terms: index.html, form, submit button, POST request, question session, GET, data, template, referenced before assignment, Tabnine
6.2.1 Persisting the session
The section uses a visible session ID to check session identity, explores cookie-based persistence with Tabnine, and shows why the suggested change needs refactoring.
- Visible session ID: Explain how displaying the session ID helps check that the application is working with the same session.
Why it matters: Seeing the ID gives you a simple way to check which session the page is using. - Cookie based session persistence: Describe the proposed way to retain a user's session if they accidentally close the browser.
Why it matters: The cookie is intended to let the application retain the user's session across an accidental browser closure. - Uncreated session error: Explain why the attempted change fails on refresh and why the existing session-creation flow needs refactoring.
Why it matters: The error shows why generated code needs checking against the application's actual flow.
Key terms: session_id, templates/index.html, run.py, cookie, Session object, session.sid, session ID, session, POST, refactor
6.2.2 Refactoring session creation
The section moves session creation into the index page, uses a cookie to retain the session ID, and shows why retaining that ID does not yet retain the question set.
- Session creation on page load: Explain why session creation moves from a button-triggered POST into the index method, and how the page handles a missing versus an existing session ID.
Why it matters: A page load can establish or reuse a session without requiring a separate button press. - Session ID cookie response: Describe how the generated session ID is stored in a Flask cookie when a new session is created.
Why it matters: The cookie gives later page loads a way to recognize the existing session. - Persistent ID changing questions: Distinguish keeping the same session ID from keeping the same question set, and explain the remaining problem seen on refresh.
Why it matters: A stable session identifier does not prove that all session-related behavior is working correctly. - Verification of generated code: Explain why the section calls for testing AI-generated changes beyond checking that the page appears to work.
Why it matters: Checking actual behavior catches problems such as changing questions behind an unchanged session ID.
Key terms: POST, index method, database connection, session ID, cookie, session_id, response.set_cookie, rendered template, question set, refresh
6.2.3 Refactoring our question set method
The section fixes question-set loading so a returning visitor keeps the questions associated with their session instead of receiving a new random set on each visit.
- Session-based question set flow: Explain how the application should use a session ID stored in a cookie to choose between creating a new session and loading an existing session’s questions.
Why it matters: The session ID is what lets the application show a returning visitor the same questions. - Question set method refactoring: Describe why the current method produces new random questions on each visit and how passing it the session ID fixes that behavior. State what a browser refresh demonstrates after the change.
Why it matters: Passing the ID to the method makes the intended session behavior visible and testable.
Key terms: session ID, cookie, question set, in-place refactoring
6.2.4 Creating an end session function that ends the test
The section adds a way to end a quiz session by deleting its cookie and refreshing the page, while emphasizing that AI-generated code still needs developer judgment.
- End Session Button Behavior: Explain how the end-session button lets a user start over: it deletes the session cookie and refreshes the page, which displays a new session with new questions.
Why it matters: A user needs a simple way to abandon the current test and begin again. - Developer Judgment With AI: Explain why the developer must evaluate and adapt AI-generated suggestions rather than treat the AI as an autonomous developer.
Why it matters: AI suggestions are useful starting points, but the developer is accountable for the resulting application.
Key terms: cookie, end the test, refresh the page, new session, AI as an accelerator, not an autopilot, domain knowledge, architectural goals
6.3 Summary
Where this is used later
- (chapter intro) (chapter 7) · The application has backend functionality that needs a usable interface.
- Gemini Results (chapter 7) · The application already has backend work for the quiz that the proposed interface would use.
- Blackbox AI results (chapter 7) · The quiz application already has backend work for its session and question flow.
- Describing the flow of our application (chapter 7) · The application already has a way to end a test.
Concepts explained in this chapter
- testA test case is a defined input, execution condition, and expected result used to evaluate software behavior.
- TabnineTabnine is an AI-powered programming assistant that provides context-aware code suggestions in supported code editors.
- debuggingDebugging is the process of locating, diagnosing, and correcting defects in software.
- contextContext is the surrounding conversation history, instructions, assumptions, and other information that determines the meaning and intent of an input.
- promptA prompt is natural-language input that instructs a generative artificial-intelligence system what response or result to produce.
- diffA diff is a representation of additions, deletions, and other differences between two versions of text or data.
- integrity errorAn integrity error is a database-related error raised when an operation violates an integrity constraint such as uniqueness or referential integrity.
- unique constraintA unique constraint is a database rule requiring values in a column or column group to be distinct across records.
- cookieA cookie is a small piece of data that a web browser stores and sends with requests to preserve client-specific state.
- session IDA session identifier is a value that uniquely identifies a user's active application session.
- sessionA session is a recorded instance of a student's practice test that tracks its questions, answers, and result counts.
- refactoringCode refactoring is the restructuring of existing source code to improve its internal organization without changing its externally observable behavior.
- request messagePOST is the HTTP request method for submitting data to a server for processing, often creating or changing a resource.
- web formAn HTML form is a browser interface element that groups controls for collecting and submitting user input.
- code generationCode generation is the automated production of source code from natural-language instructions, existing code, or other structured input.
- domain knowledgeDomain-specific knowledge is specialized understanding of the problem area to which software is applied.
- question setA question set is a grouped collection of questions assembled for a particular assessment or practice activity.
- AI assistanceA conversational programming approach in which developers guide an AI system with natural-language requests instead of detailed specifications.
- separation of concernsSeparation of concerns is a design principle that assigns distinct responsibilities to separate software components so they do not overlap unnecessarily.
- HTTP GETAn HTTP request that retrieves a resource or representation from a specified server endpoint.
← Chapter 5: Using Blackbox AI to generate base code
Chapter 7: Building user interfaces with ChatGPT →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.