Val Town Code SearchReturn to Val Town

1# Database
2
3This app uses [Val Town SQLite](https://docs.val.town/std/sqlite/) to manage data. Every Val Town account comes with a free SQLite database, hosted on [Turso](https://turso.tech/). This folder is broken up into two files:
4
5* `migrations.ts` - code to set up the database tables the app needs
6* `queries.ts` - functions to run queries against those tables, which are imported and used in the main Hono server in `/backend/index.ts`
7
8## Migrations
9
10In `backend/database/migrations.ts`, this app creates a new SQLite table `reactHonoStarter_messages` to store messages. 
11
12This "migration" runs once on every app startup because it's imported in `index.ts`. You can comment this line out for a slight (30ms) performance improvement on cold starts. It's left in so that users who fork this project will have the migration run correctly.
13
14SQLite has much more limited support for altering existing tables as compared to other databases. Often it's easier to create new tables with the schema you want, and then copy the data over. Happily LLMs are quite good at those sort of database operations, but please reach out in the [Val Town Discord](https://discord.com/invite/dHv45uN5RY) if you need help.
15
16## Queries
17
18The queries file is where running the migrations happen in this app. It'd also be reasonable for that to happen in index.ts, or as is said above, for that line to be commented out, and only run when actual changes are made to your database schema.
19
20The queries file exports functions to get and write data. It relies on shared types and data imported from the `/shared` directory.

374];
375
376// Insert memories into the database
377async function insertDemoMemories() {
378  try {
415    await insertDemoMemories();
416
417    console.log("Demo database successfully populated!");
418    return "Demo database successfully populated!";
419  } catch (error) {
420    console.error("Error populating demo database:", error);
421    throw error;
422  }

2
3/**
4 * Retrieves all memories from the database
5 * @param includeDate Whether to include date-specific memories or not
6 * @param startDate Optional start date to filter memories from (ISO format)

6import { Hono } from "npm:hono";
7import { type Memory } from "../shared/types.ts";
8import { createMemory, deleteMemory, getAllMemories, updateMemory } from "./database/queries.ts";
9
10const app = new Hono();

34
35/**
36 * Store a chat message in the database
37 */
38export async function storeChatMessage(

130  }
131
132  console.log(`Weather forecast updated in the database.`);
133  return summary;
134}

125    }
126
127    console.log(`Calendar events imported into the database.`);
128    return events;
129  } catch (error) {

208```
209├── backend/
210│   ├── database/
211│   │   ├── migrations.ts    # Schema definitions
212│   │   ├── queries.ts       # DB query functions
270- Handle API calls properly with proper error catching
271
272### Database Patterns
273- Run migrations on startup or comment out for performance
274- Change table names when modifying schemas rather than altering

548    }
549    const domain = payload.policyDomain.toLowerCase();
550    // Mock Database / Retrieval Logic
551    const mockKB = {
552      "environmental": [

1---
2title: "Post-mortem: A Backward Incompatible Database Migration"
3description: Val runs failed due to a database migration that was not backward compatible
4pubDate: 2025-04-02T00:00:00.000Z
5author: Sophie Houser
8Today at 10:11am we experienced a 12-minute outage, which caused HTTP vals to
9return 503 errors and other types of vals to fail. In the end, the root cause
10was a deployment timing issue where database migrations were deployed
11successfully, but our application code deployment hung for several minutes. The
12new database migrations were incompatible with the old application code and
13crashed the process.
14
15We aim to make all database migrations maintain backward compatibility, but in
16this case, we only discovered through the delayed deployment feedback that the
17new migrations were not compatible with previous versions.
39
40Reliability is important to us and we’ve taken steps to make sure this doesn’t
41happen again. We’ve added a test to ensure database migrations are backward
42compatible, which we’ll run before we deploy any new code that includes database
43migrations.
44