Database
The SDK exposes a small database API for application-owned relational data. Use Table to define SQLModel(opens in new tab) tables with LongLink audit fields, and use async with get_session() to open an async SQLAlchemy(opens in new tab) database session.
| Environment | Database backend |
|---|---|
Testing | memory SQLite database for isolated test runs. |
Development | dev.db SQLite database for local development. |
Production | PostgreSQL database scoped to the application schema. |
In production, the LongLink Platform provisions the organization database, shared user schema, and application schema, then injects the runtime connection settings into the application.
Usage
pythonfrom longlink import Table, get_sessionfrom sqlmodel import Fieldclass Project(Table, table=True):id: int | None = Field(default=None, primary_key=True)name: strasync def create_project() -> None:async with get_session() as session:session.add(Project(name="Launch"))await session.commit()
Migrations
After you add or change models, run Alembic(opens in new tab) migrations to keep the database schema aligned:
bashlonglink migrate
This manages only application-owned tables in the application schema. The LongLink Platform separately executes the SDK-owned migrations for shared tables such as users.
Users
Users are managed by the LongLink platform and exposed by the SDK. Application code should not create, update, or authenticate users directly; use User as read-only display data when you need to show who created or changed a row.
Models that inherit from Table expose user relationships such as created_by and updated_by. Keep your own domain fields separate from platform user data.
pythonfrom longlink import User, get_sessionfrom sqlmodel import selectasync def list_project_creators() -> list[User | None]:async with get_session() as session:result = await session.exec(select(Project))return [project.created_by for project in result.all()]