Detailed description explaining the business purpose and usage of the model.
Should include:
IMPORTANT: Description must be written in English. Example: "Customer information, but not a person but a connection basis..."
Array of foreign key fields that reference other models.
These establish relationships between models and include Prisma relation directives. Can be nullable (optional relationships) or required (mandatory relationships). May have unique constraints for 1:1 relationships.
Array of GIN (Generalized Inverted Index) indexes for full-text search.
Used specifically for PostgreSQL text search capabilities using trigram operations. Applied to text fields that need fuzzy matching or partial text search. Examples: searching names, nicknames, titles, content bodies.
Indicates whether this model represents a materialized view for performance optimization.
Materialized views are read-only computed tables that cache complex query results. They're marked as "@\hidden" in documentation and prefixed with "mv_" in naming. Examples: mv_shopping_sale_last_snapshots, mv_shopping_cart_commodity_prices
Name of the Prisma model (database table name).
MUST use snake_case naming convention. Examples: "shopping_customers", "shopping_sale_snapshots", "bbs_articles" Materialized views use "mv_" prefix: "mv_shopping_sale_last_snapshots"
Array of regular data fields that don't reference other models.
Include business data like names, descriptions, timestamps, flags, amounts, etc. Common patterns: created_at, updated_at, deleted_at for soft deletion and auditing.
Array of regular indexes for query performance optimization.
Speed up common query patterns like filtering by foreign keys, date ranges, or frequently searched fields. Examples: indexes on created_at, foreign key fields, search fields.
The primary key field of the model.
In all uploaded schemas, primary keys are always UUID type with "@\id" directive. Usually named "id" and marked with "@\db.Uuid" for PostgreSQL mapping.
Specifies the architectural stance of this model within the database system.
This property defines how the table positions itself in relation to other tables and what role it plays in the overall data architecture, particularly for API endpoint generation and business logic organization.
"primary" - Main Business EntityTables that represent core business concepts and serve as the primary subjects of user operations. These tables typically warrant independent CRUD API endpoints since users directly interact with these entities.
Key principle: If users need to independently create, search, filter, or manage entities regardless of their parent context, the table should be primary stance.
API Requirements:
Why bbs_article_comments is primary, not subsidiary:
Although comments belong to articles, they require independent management:
If comments were subsidiary, these operations would be impossible or require inefficient nested queries through parent articles.
Characteristics:
Examples:
bbs_articles - Forum posts that users create, edit, and managebbs_article_comments - User comments that require independent
management"subsidiary" - Supporting/Dependent EntityTables that exist to support primary entities but are not independently managed by users. These tables are typically managed through their parent entities and may not need standalone API endpoints.
Characteristics:
Examples:
bbs_article_snapshot_files - Files attached to article snapshotsbbs_article_snapshot_tags - Tags associated with article snapshotsbbs_article_comment_snapshot_files - Files attached to comment
snapshots"snapshot" - Historical/Versioning EntityTables that capture point-in-time states of primary entities for audit trails, version control, or historical tracking. These tables record changes but are rarely modified directly by users.
Characteristics:
Examples:
bbs_article_snapshots - Historical states of articlesbbs_article_comment_snapshots - Comment modification historyThe stance property guides automatic API endpoint generation:
"primary" → Generate full CRUD endpoints based on business
requirements"subsidiary" → Evaluate carefully; often managed through parent
entities"snapshot" → Typically read-only endpoints for historical data
access // Primary business entity - needs full CRUD API
{
name: "bbs_articles",
stance: "primary",
description: "Forum articles that users create and manage independently"
}
// Another primary entity - despite being "child" of articles
{
name: "bbs_article_comments",
stance: "primary",
description: "User comments requiring independent search and management"
}
// Subsidiary entity - managed through snapshot operations
{
name: "bbs_article_snapshot_files",
stance: "subsidiary",
description: "Files attached to article snapshots, managed via snapshot APIs"
}
// Snapshot entity - read-only historical data
{
name: "bbs_article_snapshots",
stance: "snapshot",
description: "Historical states of articles for audit and versioning"
}
Array of unique indexes for enforcing data integrity constraints.
Ensure uniqueness across single or multiple columns. Examples: unique email addresses, unique codes within a channel, unique combinations like (channel_id, nickname).
Interface representing a single Prisma model (database table).
Based on the uploaded schemas, models follow specific patterns: