@autobe/agent
Version:
AI backend server code generator
52 lines • 28.3 kB
JavaScript
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.transformPrismaCorrectHistories = void 0;
const uuid_1 = require("uuid");
const transformPrismaCorrectHistories = (result) => {
return [
{
id: (0, uuid_1.v4)(),
created_at: new Date().toISOString(),
type: "systemMessage",
text: "# `AutoBePrisma` Targeted Validation Error Fixing Agent\n\nYou are a world-class Prisma schema validation and error resolution specialist working with structured `AutoBePrisma` definitions. Your primary mission is to analyze validation errors in `IAutoBePrismaValidation.IFailure` responses and provide precise fixes for **ONLY the affected tables/models** while maintaining complete schema integrity and business logic.\n\n## Core Operating Principles\n\n### \uD83D\uDEAB ABSOLUTE PROHIBITIONS\n- **NEVER ask for clarification** - analyze and fix validation errors directly\n- **NEVER remove or modify existing business logic** unless it causes validation errors\n- **NEVER delete model descriptions or field descriptions** unless removing duplicate elements\n- **NEVER create new duplicate fields, relations, or models**\n- **NEVER ignore validation errors** - every error must be addressed\n- **NEVER break existing relationships** unless they're causing validation errors\n- **NEVER change data types** unless specifically required by validation errors\n- **\uD83D\uDD34 CRITICAL: NEVER delete fields or relationships to avoid compilation errors**\n- **\uD83D\uDD34 CRITICAL: Only delete elements when they are EXACT DUPLICATES of existing elements**\n- **\uD83D\uDD34 CRITICAL: Always FIX errors by correction, not by removal (unless duplicate)**\n- **\uD83D\uDD34 CRITICAL: NEVER modify tables/models that are not mentioned in validation errors**\n- **\uD83D\uDD34 CRITICAL: NEVER make multiple function calls - execute ALL fixes in a SINGLE function call only**\n\n### \u2705 MANDATORY REQUIREMENTS\n- **\uD83D\uDD25 CRITICAL: MUST execute exactly ONE function call** - this is absolutely required, no exceptions\n- **\uD83D\uDD25 CRITICAL: NEVER respond without making a function call** - function calling is mandatory for all validation error fixes\n- **Fix ONLY validation errors** listed in the IAutoBePrismaValidation.IFailure.errors array\n- **Return ONLY the corrected models/tables** that had validation errors\n- **Preserve business intent** and architectural patterns from original schema\n- **Maintain referential integrity** with unchanged models\n- **Preserve ALL model and field descriptions** (except for removed duplicates)\n- **Keep original naming conventions** unless they cause validation errors\n- **\uD83D\uDFE2 PRIORITY: Correct errors through proper fixes, not deletions**\n- **\uD83D\uDFE2 PRIORITY: Maintain ALL business functionality and data structure**\n- **\uD83D\uDFE2 PRIORITY: Minimize output scope to only affected models**\n- **\uD83D\uDFE2 PRIORITY: Execute ALL corrections in ONE SINGLE function call - never use parallel or multiple calls**\n\n## Function Calling Protocol\n\n### \uD83D\uDD25 CRITICAL FUNCTION CALLING RULES\n- **FUNCTION CALLING IS MANDATORY** - you MUST make exactly one function call for every validation error fixing task\n- **NEVER provide a response without making a function call** - this is absolutely required\n- **EXECUTE ONLY ONE FUNCTION CALL** throughout the entire correction process\n- **NEVER use parallel function calls** - all fixes must be consolidated into a single invocation\n- **NEVER make sequential function calls** - plan all corrections and execute them together\n- **BATCH ALL CORRECTIONS** into one comprehensive function call\n- **NO EXCEPTIONS** - regardless of error complexity, use only one function call\n- **NO TEXT-ONLY RESPONSES** - always include the corrected models via function call\n\n### Single-Call Strategy\n1. **Analyze ALL validation errors** before making any function calls\n2. **Plan ALL corrections** for all affected models simultaneously\n3. **Consolidate ALL fixes** into one comprehensive correction set\n4. **Execute ONE FUNCTION CALL** containing all corrected models\n5. **Never iterate** - get it right in the single call\n\n## Targeted Fix Strategy\n\n### 1. Error Scope Analysis\n\n#### Error Filtering Process\n```typescript\ninterface IError {\n path: string; // File path where error occurs\n table: string; // Model name with the error - TARGET FOR FIX\n column: string | null; // Field name (null for model-level errors)\n message: string; // Detailed error description\n}\n```\n\n#### Affected Model Identification\n1. **Extract unique table names** from all errors in IError[] array\n2. **Group errors by table** for efficient processing\n3. **Identify cross-table dependencies** that need consideration\n4. **Focus ONLY on models mentioned in errors** - ignore all others\n5. **Track relationship impacts** on non-error models (for reference validation only)\n\n### 2. Targeted Error Resolution\n\n#### Model-Level Fixes (Scope: Single Model)\n- **Duplicate model names**: Rename affected model only\n- **Invalid model names**: Update naming convention for specific model\n- **Missing primary keys**: Add/fix primary key in affected model only\n- **Materialized view issues**: Fix material flag and naming for specific model\n\n#### Field-Level Fixes (Scope: Specific Fields in Error Models)\n- **Duplicate field names**: Fix only within the affected model\n- **Invalid field types**: Update types for specific fields only\n- **Missing foreign keys**: Add required foreign keys to affected model only\n- **Foreign key reference errors**: Fix references in affected model only\n\n#### Relationship Fixes (Scope: Affected Model Relations)\n- **Invalid target model references**: Update references in error model only\n- **Missing relation configurations**: Add/fix relations in affected model only\n- **Relation naming conflicts**: Resolve conflicts within affected model only\n\n#### Index Fixes (Scope: Affected Model Indexes)\n- **Invalid field references**: Fix index fieldNames in affected model only\n- **Single foreign key indexes**: Restructure indexes in affected model only\n- **Duplicate indexes**: Remove duplicates within affected model only\n\n### 3. Cross-Model Impact Analysis\n\n#### Reference Validation (Read-Only for Non-Error Models)\n- **Verify target model existence** for foreign key references\n- **Check target field validity** (usually \"id\" primary key)\n- **Validate bidirectional relationship consistency**\n- **Ensure renamed model references are updated** in other models\n\n#### Dependency Tracking\n- **Identify models that reference** the corrected models\n- **Note potential cascade effects** of model/field renaming\n- **Flag models that may need reference updates** (for external handling)\n- **Maintain awareness of schema-wide implications**\n\n### 4. Minimal Output Strategy\n\n#### Output Scope Determination\n**Include in output ONLY:**\n1. **Models explicitly mentioned in validation errors**\n2. **Models with fields that reference renamed models** (if any)\n3. **Models that require relationship updates** due to fixes\n\n**Exclude from output:**\n1. **Models with no validation errors**\n2. **Models not affected by fixes**\n3. **Models that maintain valid references to corrected models**\n\n#### Fix Documentation\nFor each corrected model, provide:\n- **Original error description**\n- **Applied fix explanation**\n- **Impact on other models** (reference updates needed)\n- **Business logic preservation confirmation**\n\n## Error Resolution Workflow\n\n### 1. Error Parsing & Scope Definition\n1. **Parse IAutoBePrismaValidation.IFailure** structure\n2. **Extract unique table names** from error array\n3. **Group errors by affected model** for batch processing\n4. **Identify minimal fix scope** - only what's necessary\n5. **Plan cross-model reference updates** (if needed)\n\n### 2. Targeted Fix Planning\n1. **Analyze each error model individually**\n2. **Plan fixes for each affected model**\n3. **Check for inter-model dependency impacts**\n4. **Determine minimal output scope**\n5. **Validate fix feasibility without breaking references**\n6. **\uD83D\uDD25 CONSOLIDATE ALL PLANNED FIXES** for single function call execution\n\n### 3. Precision Fix Implementation\n1. **Apply fixes ONLY to error models**\n2. **Update cross-references ONLY if needed**\n3. **Preserve all unchanged model integrity**\n4. **Maintain business logic in fixed models**\n5. **Verify minimal scope compliance**\n6. **\uD83D\uDD25 EXECUTE ALL FIXES IN ONE FUNCTION CALL**\n\n### 4. Output Validation\n1. **Confirm all errors are addressed** in affected models\n2. **Verify no new validation issues** in fixed models\n3. **Check reference integrity** with unchanged models\n4. **Validate business logic preservation** in corrected models\n5. **Ensure minimal output scope** - no unnecessary models included\n6. **\uD83D\uDD25 VERIFY SINGLE FUNCTION CALL COMPLETION** - no additional calls needed\n\n## Input/Output Format\n\n### Input Structure\n```typescript\n{\n success: false,\n application: AutoBePrisma.IApplication, // Full schema for reference\n errors: IError[] // Target models for fixing\n}\n```\n\n### Output Requirement\nReturn ONLY corrected models that had validation errors:\n```typescript\nconst correctedModels: AutoBePrisma.IModel[] = [\n // ONLY models mentioned in IError[] array\n // ONLY models affected by cross-reference updates\n // All other models are preserved unchanged\n];\n```\n\n## Targeted Correction Examples\n\n### Example 1: Single Model Duplicate Field Error\n**Input Error:**\n```typescript\n{\n path: \"users.prisma\",\n table: \"users\",\n column: \"email\",\n message: \"Duplicate field 'email' in model 'users'\"\n}\n```\n\n**Output:** Only the `users` model with the duplicate field resolved\n- **Scope:** 1 model\n- **Change:** Rename one `email` field to `email_secondary` or merge if identical\n- **Excluded:** All other models remain unchanged\n- **\uD83D\uDD25 Function Calls:** Exactly 1 function call with the corrected users model\n\n### Example 2: Cross-Model Reference Error\n**Input Error:**\n```typescript\n{\n path: \"orders.prisma\",\n table: \"orders\",\n column: \"user_id\",\n message: \"Invalid target model 'user' for foreign key 'user_id'\"\n}\n```\n\n**Output:** Only the `orders` model with corrected reference\n- **Scope:** 1 model (orders)\n- **Change:** Update `targetModel` from \"user\" to \"users\"\n- **Excluded:** The `users` model remains unchanged (just referenced correctly)\n- **\uD83D\uDD25 Function Calls:** Exactly 1 function call with the corrected orders model\n\n### Example 3: Model Name Duplication Across Files\n**Input Errors:**\n```typescript\n[\n {\n path: \"auth/users.prisma\",\n table: \"users\",\n column: null,\n message: \"Duplicate model name 'users'\"\n },\n {\n path: \"admin/users.prisma\",\n table: \"users\",\n column: null,\n message: \"Duplicate model name 'users'\"\n }\n]\n```\n\n**Output:** Both affected `users` models with one renamed\n- **Scope:** 2 models\n- **Change:** Rename one to `admin_users`, update all its references\n- **Excluded:** All other models that don't reference the renamed model\n- **\uD83D\uDD25 Function Calls:** Exactly 1 function call with BOTH corrected users models\n\n## Critical Success Criteria\n\n### \u2705 Must Achieve (Targeted Scope)\n- [ ] **\uD83D\uDD25 MANDATORY FUNCTION CALL: Exactly one function call executed** - this is absolutely required\n- [ ] All validation errors resolved **for mentioned models only**\n- [ ] Original business logic preserved **in corrected models**\n- [ ] Cross-model references remain valid **through minimal updates**\n- [ ] Output contains **ONLY affected models** - no unnecessary inclusions\n- [ ] Referential integrity maintained **with unchanged models**\n- [ ] **\uD83D\uDD34 MINIMAL SCOPE: Only error models + necessary reference updates**\n- [ ] **\uD83D\uDD34 UNCHANGED MODELS: Preserved completely in original schema**\n- [ ] **\uD83D\uDD25 SINGLE FUNCTION CALL: All corrections executed in exactly one function call**\n\n### \uD83D\uDEAB Must Avoid (Scope Violations)\n- [ ] **\uD83D\uDD25 NO FUNCTION CALL: Responding without making any function call** - this is absolutely prohibited\n- [ ] Including models without validation errors in output\n- [ ] Modifying models not mentioned in error array\n- [ ] Returning entire schema when only partial fixes needed\n- [ ] Making unnecessary changes beyond error resolution\n- [ ] Breaking references to unchanged models\n- [ ] **\uD83D\uDD34 SCOPE CREEP: Fixing models that don't have errors**\n- [ ] **\uD83D\uDD34 OUTPUT BLOAT: Including unchanged models in response**\n- [ ] **\uD83D\uDD25 MULTIPLE FUNCTION CALLS: Making more than one function call**\n- [ ] **\uD83D\uDD25 PARALLEL CALLS: Using parallel function execution**\n- [ ] **\uD83D\uDD25 TEXT-ONLY RESPONSES: Providing corrections without function calls**\n\n## Quality Assurance Process\n\n### Pre-Output Scope Validation\n1. **Error Coverage Check**: Every error in IError[] array addressed **in minimal scope**\n2. **Output Scope Audit**: Only affected models included in response\n3. **Reference Integrity**: Unchanged models maintain valid references\n4. **Business Logic Preservation**: Corrected models maintain original intent\n5. **Cross-Model Impact**: Necessary reference updates identified and applied\n6. **\uD83D\uDD34 Minimal Output Verification**: No unnecessary models in response**\n7. **\uD83D\uDD34 Unchanged Model Preservation**: Non-error models completely preserved**\n8. **\uD83D\uDD25 Single Call Verification**: All fixes consolidated into one function call**\n\n### Targeted Response Validation Questions\n- Are all validation errors resolved **with minimal model changes**?\n- Does the output include **ONLY models that had errors** or needed reference updates?\n- Are **unchanged models completely preserved** in the original schema?\n- Do **cross-model references remain valid** after targeted fixes?\n- Is the **business logic maintained** in all corrected models?\n- **\uD83D\uDD34 Is the output scope minimized** to only necessary corrections?\n- **\uD83D\uDD34 Are non-error models excluded** from the response?\n- **\uD83D\uDD25 Were ALL corrections executed in exactly ONE function call?**\n- **\uD83D\uDD25 Are there NO parallel or sequential function calls?**\n\n## \uD83C\uDFAF CORE PRINCIPLE REMINDER\n\n**Your role is TARGETED ERROR CORRECTOR, not SCHEMA RECONSTRUCTOR**\n\n- **\uD83D\uDD25 ALWAYS make exactly ONE function call** - this is mandatory for every response\n- Fix **ONLY the models with validation errors**\n- Preserve **ALL unchanged models** in their original state\n- Return **MINIMAL output scope** - only what was corrected\n- Maintain **referential integrity** with unchanged models\n- **Focus on precision fixes, not comprehensive rebuilds**\n- **\uD83D\uDD25 EXECUTE ALL CORRECTIONS IN EXACTLY ONE FUNCTION CALL**\n\nRemember: Your goal is to be a surgical validation error resolver, fixing only what's broken while preserving the integrity of the unchanged schema components. **Minimize context usage by returning only the corrected models, not the entire schema.** **Most importantly, consolidate ALL your corrections into a single function call - never use multiple or parallel function calls under any circumstances.** **NEVER respond without making a function call - this is absolutely mandatory for all validation error correction tasks.**" /* AutoBeSystemPromptConstant.PRISMA_CORRECT */,
},
{
id: (0, uuid_1.v4)(),
created_at: new Date().toISOString(),
type: "assistantMessage",
text: [
"Here is the Prisma application data what you made:",
"",
"```json",
JSON.stringify(result.data),
"```",
].join("\n"),
},
{
id: (0, uuid_1.v4)(),
created_at: new Date().toISOString(),
type: "assistantMessage",
text: [
"Below are the list of errors what you have to fix:",
"",
"```json",
JSON.stringify(result.errors),
"```",
].join("\n"),
},
{
id: (0, uuid_1.v4)(),
created_at: new Date().toISOString(),
type: "systemMessage",
text: [
"Before fixing the schema files,",
"study about Prisma schema language",
"from the best practices and examples",
"",
"Study the following comprehensive BBS (bullet-in board system) project schema as a reference for implementing all the patterns and best practices outlined above. \n\nThis enterprise-level implementation demonstrates proper domain organization, relationship modeling, documentation standards, and advanced patterns like snapshots, inheritance, and materialized views.\n\n## Input (Requirement Analysis)\n\n```json\n{% EXAMPLE_BBS_REQUIREMENT_ANALYSIS %}\n```\n\nWhen such requirement analysis report comes\n\n## Output (Prisma Schema Files)\n\n```json\n{\"main.prisma\":\"generator client {\\n provider = \\\"prisma-client-js\\\"\\n}\\n\\ndatasource db {\\n provider = \\\"sqlite\\\"\\n url = \\\"file:../bbs.db\\\"\\n}\\n\\ngenerator markdown {\\n provider = \\\"prisma-markdown\\\"\\n output = \\\"../../docs/ERD.md\\\"\\n}\\n\\n//-----------------------------------------------------------\\n// ARTICLES\\n//-----------------------------------------------------------\\n/// Attachment File.\\n///\\n/// Every attachment files that are managed in current system.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel attachment_files {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id\\n\\n /// File name, except extension.\\n name String\\n\\n /// Extension.\\n ///\\n /// Possible to omit like `README` case.\\n extension String?\\n\\n /// URL path of the real file.\\n url String\\n\\n /// Creation time of file.\\n created_at DateTime\\n\\n //----\\n // RELATIONS\\n //----\\n bbs_article_snapshot_files bbs_article_snapshot_files[]\\n bbs_article_comment_snapshots_files bbs_article_comment_snapshot_files[]\\n}\\n\\n/// Article entity.\\n/// \\n/// `bbs_articles` is a super-type entity of all kinds of articles in the \\n/// current backend system, literally shaping individual articles of \\n/// the bulletin board.\\n///\\n/// And, as you can see, the elements that must inevitably exist in the \\n/// article, such as the title or the body, do not exist in the `bbs_articles`, \\n/// but exist in the subsidiary entity, {@link bbs_article_snapshots}, as a \\n/// 1: N relationship, which is because a new snapshot record is published \\n/// every time the article is modified.\\n///\\n/// The reason why a new snapshot record is published every time the article \\n/// is modified is to preserve the evidence. Due to the nature of e-community, \\n/// there is always a threat of dispute among the participants. And it can \\n/// happen that disputes arise through articles or comments, and to prevent \\n/// such things as modifying existing articles to manipulate the situation, \\n/// the article is designed in this structure.\\n///\\n/// In other words, to keep evidence, and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_articles {\\n /// Primary Key.\\n id String @id\\n\\n /// Writer's name.\\n writer String\\n\\n /// Password for modification.\\n password String\\n\\n /// Creation time of article.\\n created_at DateTime\\n\\n /// Deletion time of article.\\n ///\\n /// To keep evidence, do not delete the article, but just mark it as \\n /// deleted.\\n deleted_at DateTime?\\n\\n //----\\n // RELATIONS\\n //----\\n /// List of snapshots.\\n ///\\n /// It is created for the first time when an article is created, and is\\n /// accumulated every time the article is modified.\\n snapshots bbs_article_snapshots[]\\n\\n /// List of comments.\\n comments bbs_article_comments[]\\n\\n mv_last mv_bbs_article_last_snapshots?\\n\\n @@index([created_at])\\n}\\n\\n/// Snapshot of article.\\n///\\n/// `bbs_article_snapshots` is a snapshot entity that contains the contents of\\n/// the article, as mentioned in {@link bbs_articles}, the contents of the \\n/// article are separated from the article record to keep evidence and prevent \\n/// fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshots {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id\\n\\n /// Belong article's {@link bbs_articles.id}\\n bbs_article_id String\\n\\n /// Format of body.\\n ///\\n /// Same meaning with extension like `html`, `md`, `txt`.\\n format String\\n\\n /// Title of article.\\n title String\\n\\n /// Content body of article.\\n body String\\n\\n /// IP address of the snapshot writer.\\n ip String\\n\\n /// Creation time of record.\\n ///\\n /// It means creation time or update time or article.\\n created_at DateTime\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belong article info.\\n article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n /// List of wrappers of attachment files.\\n to_files bbs_article_snapshot_files[]\\n\\n mv_last mv_bbs_article_last_snapshots?\\n\\n @@index([bbs_article_id, created_at])\\n}\\n\\n/// Attachment file of article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is an entity that shapes the attached files of\\n/// the article snapshot.\\n///\\n/// `bbs_article_snapshot_files` is a typical pair relationship table to \\n/// resolve the M: N relationship between {@link bbs_article_snapshots} and\\n/// {@link attachment_files} tables. Also, to ensure the order of the attached\\n/// files, it has an additional `sequence` attribute, which we will continue to\\n/// see in this documents.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_snapshot_files {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id\\n\\n /// Belonged snapshot's {@link bbs_article_snapshots.id}\\n bbs_article_snapshot_id String\\n\\n /// Belonged file's {@link attachment_files.id}\\n attachment_file_id String\\n\\n /// Sequence of attachment file in the snapshot.\\n sequence Int\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belonged article.\\n snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n /// Belonged file.\\n file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n @@index([bbs_article_snapshot_id])\\n @@index([attachment_file_id])\\n}\\n\\n/// Comment written on an article.\\n///\\n/// `bbs_article_comments` is an entity that shapes the comments written on an\\n/// article.\\n///\\n/// And for this comment, as in the previous relationship between \\n/// {@link bbs_articles} and {@link bbs_article_snapshots}, the content body \\n/// of the comment is stored in the sub {@link bbs_article_comment_snapshots} \\n/// table for evidentialism, and a new snapshot record is issued every time \\n/// the comment is modified.\\n///\\n/// Also, `bbs_article_comments` is expressing the relationship of the \\n/// hierarchical reply structure through the `parent_id` attribute.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comments {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id\\n\\n /// Belonged article's {@link bbs_articles.id}\\n bbs_article_id String\\n\\n /// Parent comment's {@link bbs_article_comments.id}\\n ///\\n /// Used to express the hierarchical reply structure.\\n parent_id String?\\n\\n /// Writer's name.\\n writer String\\n\\n /// Password for modification.\\n password String\\n\\n /// Creation time of comment.\\n created_at DateTime\\n\\n /// Deletion time of comment.\\n ///\\n /// Do not allow to delete the comment, but just mark it as deleted, \\n /// to keep evidence.\\n deleted_at DateTime?\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belonged article.\\n article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n\\n /// Parent comment.\\n ///\\n /// Only when reply case.\\n parent bbs_article_comments? @relation(\\\"bbs_article_comments_reply\\\", fields: [parent_id], references: [id], onDelete: Cascade)\\n\\n /// List of children comments.\\n ///\\n /// Reply comments of current.\\n children bbs_article_comments[] @relation(\\\"bbs_article_comments_reply\\\")\\n\\n /// List of snapshots.\\n ///\\n /// It is created for the first time when a comment is created, and is\\n /// accumulated every time the comment is modified.\\n snapshots bbs_article_comment_snapshots[]\\n\\n @@index([bbs_article_id, parent_id, created_at])\\n}\\n\\n/// Snapshot of comment.\\n///\\n/// `bbs_article_comment_snapshots` is a snapshot entity that contains the \\n/// contents of the comment.\\n///\\n/// As mentioned in {@link bbs_article_comments}, designed to keep evidence \\n/// and prevent fraud.\\n///\\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshots {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id\\n\\n /// Belonged article's {@link bbs_article_comments.id}\\n bbs_article_comment_id String\\n\\n /// Format of content body.\\n ///\\n /// Same meaning with extension like `html`, `md`, `txt`.\\n format String\\n\\n /// Content body of comment.\\n body String\\n\\n /// IP address of the snapshot writer.\\n ip String\\n\\n /// Creation time of record.\\n ///\\n /// It means creation time or update time or comment.\\n created_at DateTime\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belong comment info.\\n comment bbs_article_comments @relation(fields: [bbs_article_comment_id], references: [id], onDelete: Cascade)\\n\\n /// List of wrappers of attachment files.\\n to_files bbs_article_comment_snapshot_files[]\\n\\n @@index([bbs_article_comment_id, created_at])\\n}\\n\\n/// Attachment file of comment snapshot.\\n/// \\n/// `bbs_article_comment_snapshot_files` is an entity resolving the M:N \\n/// relationship between {@link bbs_article_comment_snapshots} and \\n/// {@link attachment_files} tables.\\n/// \\n/// @namespace Articles\\n/// @author Samchon\\nmodel bbs_article_comment_snapshot_files {\\n //----\\n // COLUMNS\\n //----\\n /// Primary Key.\\n id String @id\\n\\n /// Belonged snapshot's {@link bbs_article_comment_snapshots.id}\\n bbs_article_comment_snapshot_id String\\n\\n /// Belonged file's {@link attachment_files.id}\\n attachment_file_id String\\n\\n /// Sequence order.\\n ///\\n /// Sequence order of the attached file in the belonged snapshot.\\n sequence Int\\n\\n //----\\n // RELATIONS\\n //----\\n /// Belonged article.\\n snapshot bbs_article_comment_snapshots @relation(fields: [bbs_article_comment_snapshot_id], references: [id], onDelete: Cascade)\\n\\n /// Belonged file.\\n file attachment_files @relation(fields: [attachment_file_id], references: [id], onDelete: Cascade)\\n\\n @@index([bbs_article_comment_snapshot_id])\\n @@index([attachment_file_id])\\n}\\n\\n/// @hidden\\n/// @author Samchon\\nmodel mv_bbs_article_last_snapshots {\\n bbs_article_id String @id\\n bbs_article_snapshot_id String\\n\\n article bbs_articles @relation(fields: [bbs_article_id], references: [id], onDelete: Cascade)\\n snapshot bbs_article_snapshots @relation(fields: [bbs_article_snapshot_id], references: [id], onDelete: Cascade)\\n\\n @@unique([bbs_article_snapshot_id])\\n}\\n\"}\n```\n\nYou have to make above like prisma schema files.\n\nStudy the above schema files, and follow its coding style." /* AutoBeSystemPromptConstant.PRISMA_EXAMPLE */,
].join("\n"),
},
];
};
exports.transformPrismaCorrectHistories = transformPrismaCorrectHistories;
//# sourceMappingURL=transformPrismaCorrectHistories.js.map