@autobe/compiler 0.30.0-dev.20260315 → 0.30.1

package/lib/database/validateDatabaseApplication.js

@@ -60,15 +60,15 @@ function validateDuplicatedFiles(app) {
                     path: `application.files[${container.index}]`,
                     table: null,
                     field: null,
-                    message: utils_1.StringUtil.trim `
-            File ${container.file.filename} is duplicated.
-
-            Accessors of the other duplicated files are:
-
+                    message: utils_1.StringUtil.trim `
+            File ${container.file.filename} is duplicated.
+
+            Accessors of the other duplicated files are:
+
             ${array
                         .filter((_oppo, j) => i !== j)
                         .map((oppo) => `- application.files[${oppo.index}]`)
-                        .join("\n")},
+                        .join("\n")},
           `,
                 });
             });
@@ -95,15 +95,15 @@ function validateDuplicatedModels(app) {
                     path: `application.files[${container.fileIndex}].models[${container.modelIndex}]`,
                     table: container.model.name,
                     field: null,
-                    message: utils_1.StringUtil.trim `
-            Model ${container.model.name} is duplicated.
-            
-            Accessors of the other duplicated models are:
-            
+                    message: utils_1.StringUtil.trim `
+            Model ${container.model.name} is duplicated.
+            
+            Accessors of the other duplicated models are:
+            
             ${array
                         .filter((_oppo, j) => i !== j)
                         .map((oppo) => `- application.files[${oppo.fileIndex}].models[${oppo.modelIndex}]`)
-                        .join("\n")},
+                        .join("\n")},
           `,
                 });
             });
@@ -126,15 +126,15 @@ function validateDuplicatedFields(dict, model, accessor) {
                     path,
                     table: model.name,
                     field,
-                    message: utils_1.StringUtil.trim `
-            Field ${field} is duplicated.
-            
-            Accessors of the other duplicated fields are:
-            
+                    message: utils_1.StringUtil.trim `
+            Field ${field} is duplicated.
+            
+            Accessors of the other duplicated fields are:
+            
             ${array
                         .filter((_oppo, j) => i !== j)
                         .map((a) => `- ${a}`)
-                        .join("\n")},
+                        .join("\n")},
           `,
                 });
             });
@@ -145,38 +145,38 @@ function validateDuplicatedFields(dict, model, accessor) {
                 path: `${accessor}.plainFields[${i}].name`,
                 table: model.name,
                 field: field.name,
-                message: utils_1.StringUtil.trim `
-          Field name conflicts with an existing table name.
-
-          **What happened?**
-          The field "${field.name}" in model "${model.name}" has the same name as another table "${field.name}".
-          This can cause confusion and potential issues in the generated code.
-
-          **Why is this a problem?**
-          - Naming conflicts can lead to ambiguous references in your code
-          - It may cause issues with Prisma's relation inference
-          - It makes the schema harder to understand and maintain
-
-          **How to fix this:**
-          
-          1. **If this is a denormalization field (pre-calculated value):**
-             - Consider if this field is really necessary
-             - If it's storing aggregated data from the related table, it might be better to calculate it dynamically
-             - Remove the field if it's redundant
-
-          2. **If this is a legitimate field:**
-             - Rename the field to be more descriptive
-             - Good naming examples:
-               - Instead of "user", use "user_name" or "user_id"
-               - Instead of "order", use "order_status" or "order_count"
-               - Instead of "product", use "product_name" or "product_code"
-
-          3. **Naming best practices:**
-             - Use specific, descriptive names that indicate the field's purpose
-             - Avoid using table names as field names
-             - Consider adding a suffix or prefix to clarify the field's role
-
-          Please rename the field or remove it if unnecessary.
+                message: utils_1.StringUtil.trim `
+          Field name conflicts with an existing table name.
+
+          **What happened?**
+          The field "${field.name}" in model "${model.name}" has the same name as another table "${field.name}".
+          This can cause confusion and potential issues in the generated code.
+
+          **Why is this a problem?**
+          - Naming conflicts can lead to ambiguous references in your code
+          - It may cause issues with Prisma's relation inference
+          - It makes the schema harder to understand and maintain
+
+          **How to fix this:**
+          
+          1. **If this is a denormalization field (pre-calculated value):**
+             - Consider if this field is really necessary
+             - If it's storing aggregated data from the related table, it might be better to calculate it dynamically
+             - Remove the field if it's redundant
+
+          2. **If this is a legitimate field:**
+             - Rename the field to be more descriptive
+             - Good naming examples:
+               - Instead of "user", use "user_name" or "user_id"
+               - Instead of "order", use "order_status" or "order_count"
+               - Instead of "product", use "product_name" or "product_code"
+
+          3. **Naming best practices:**
+             - Use specific, descriptive names that indicate the field's purpose
+             - Avoid using table names as field names
+             - Consider adding a suffix or prefix to clarify the field's role
+
+          Please rename the field or remove it if unnecessary.
         `,
             });
     });
@@ -202,15 +202,15 @@ function validateDuplicatedIndexes(model, accessor) {
                     path,
                     table: model.name,
                     field: null,
-                    message: utils_1.StringUtil.trim `
-            Duplicated index found (${fieldNames.join(", ")}).
-            
-            Accessors of the other duplicated indexes are:
-            
+                    message: utils_1.StringUtil.trim `
+            Duplicated index found (${fieldNames.join(", ")}).
+            
+            Accessors of the other duplicated indexes are:
+            
             ${array
                         .filter((_oppo, j) => i !== j)
                         .map((a) => `- ${a}`)
-                        .join("\n")},
+                        .join("\n")},
           `,
                 });
             });
@@ -228,13 +228,13 @@ function validateDuplicatedIndexes(model, accessor) {
                     path: `${accessor}.uniqueIndexes[${i}].fieldNames[0]`,
                     table: model.name,
                     field: null,
-                    message: utils_1.StringUtil.trim `
-            Duplicated unique index found (${subset[0]}).
-            
-            You have defined an unique index that is already included,
-            in the foreign field with unique constraint.
-            
-            Remove this unique index to avoid the duplication.
+                    message: utils_1.StringUtil.trim `
+            Duplicated unique index found (${subset[0]}).
+            
+            You have defined an unique index that is already included,
+            in the foreign field with unique constraint.
+            
+            Remove this unique index to avoid the duplication.
           `,
                 });
             const cIndex = model.uniqueIndexes.findIndex((u) => u.fieldNames.length === subset.length &&
@@ -244,45 +244,45 @@ function validateDuplicatedIndexes(model, accessor) {
                     path: `${accessor}.uniqueIndexes[${i}].fieldNames`,
                     table: model.name,
                     field: null,
-                    message: utils_1.StringUtil.trim `
-            Redundant subset unique index detected.
-
-            **What is a subset unique index problem?**
-            When you have a unique index on multiple fields, any subset of those fields is automatically unique too.
-            This is a fundamental property of unique constraints in databases.
-
-            **Current situation:**
-            - You have a unique index on: (${unique.fieldNames.join(", ")})
-            - But there's already a unique index on its subset: (${subset.join(", ")})
-            - This makes the larger unique index redundant for uniqueness purposes
-
-            **Why is this a problem?**
-            1. **Logical redundancy**: If (A) is unique, then (A, B) is automatically unique
-            2. **Performance overhead**: Maintaining unnecessary indexes slows down write operations
-            3. **Storage waste**: Each index consumes disk space
-            4. **Confusion**: It's unclear which uniqueness constraint is the intended one
-
-            **Example to illustrate:**
-            If email is unique, then (email, name) is automatically unique because:
-            - No two records can have the same email
-            - Therefore, no two records can have the same (email, name) combination
-
-            **How to fix:**
-            Choose one of these solutions based on your needs:
-
-            1. **If you need uniqueness only:**
-               - Keep just the subset unique index: (${subset.join(", ")})
-               - Remove the larger unique index
-
-            2. **If you need the multi-field index for query performance:**
-               - Keep the subset as unique index: (${subset.join(", ")})
-               - Change the larger index to a plain (non-unique) index for performance
-
-            3. **If the subset unique was added by mistake:**
-               - Remove the subset unique index
-               - Keep the multi-field unique index
-
-            Please review your uniqueness requirements and adjust accordingly.
+                    message: utils_1.StringUtil.trim `
+            Redundant subset unique index detected.
+
+            **What is a subset unique index problem?**
+            When you have a unique index on multiple fields, any subset of those fields is automatically unique too.
+            This is a fundamental property of unique constraints in databases.
+
+            **Current situation:**
+            - You have a unique index on: (${unique.fieldNames.join(", ")})
+            - But there's already a unique index on its subset: (${subset.join(", ")})
+            - This makes the larger unique index redundant for uniqueness purposes
+
+            **Why is this a problem?**
+            1. **Logical redundancy**: If (A) is unique, then (A, B) is automatically unique
+            2. **Performance overhead**: Maintaining unnecessary indexes slows down write operations
+            3. **Storage waste**: Each index consumes disk space
+            4. **Confusion**: It's unclear which uniqueness constraint is the intended one
+
+            **Example to illustrate:**
+            If email is unique, then (email, name) is automatically unique because:
+            - No two records can have the same email
+            - Therefore, no two records can have the same (email, name) combination
+
+            **How to fix:**
+            Choose one of these solutions based on your needs:
+
+            1. **If you need uniqueness only:**
+               - Keep just the subset unique index: (${subset.join(", ")})
+               - Remove the larger unique index
+
+            2. **If you need the multi-field index for query performance:**
+               - Keep the subset as unique index: (${subset.join(", ")})
+               - Change the larger index to a plain (non-unique) index for performance
+
+            3. **If the subset unique was added by mistake:**
+               - Remove the subset unique index
+               - Keep the multi-field unique index
+
+            Please review your uniqueness requirements and adjust accordingly.
           `,
                 });
         });
@@ -298,43 +298,43 @@ function validateDuplicatedIndexes(model, accessor) {
                     path: `${accessor}.plainIndexes[${i}].fieldNames`,
                     table: model.name,
                     field: null,
-                    message: utils_1.StringUtil.trim `
-            Inefficient subset index detected - superset index exists.
-
-            **What is a subset/superset index problem?**
-            In database indexing, when you have an index on (A, B, C), it can efficiently serve queries 
-            that filter by A, or by (A, B), or by (A, B, C). This is called index prefix matching.
-
-            **Current situation:**
-            - You have a plain index on: (${x.fieldNames.join(", ")})
-            - But there's already a plain index on its superset: (${y.fieldNames.join(", ")})
-            - The subset index is redundant because the superset can handle the same queries
-
-            **Why is this a problem?**
-            1. **Query efficiency**: The superset index can handle all queries the subset can
-            2. **Storage waste**: You're maintaining two indexes where one would suffice
-            3. **Write performance**: Each index slows down INSERT, UPDATE, and DELETE operations
-            4. **Maintenance overhead**: More indexes mean more work for the database
-
-            **How indexes work (example):**
-            If you have an index on (country, city, street):
-            - ✅ Can efficiently find by country
-            - ✅ Can efficiently find by country + city
-            - ✅ Can efficiently find by country + city + street
-            - ❌ Cannot efficiently find by city alone
-            - ❌ Cannot efficiently find by street alone
-
-            **How to fix:**
-            Remove the subset index (${x.fieldNames.join(", ")}) because:
-            - The superset index (${y.fieldNames.join(", ")}) already covers these queries
-            - You'll save storage space and improve write performance
-            - Query performance will remain the same
-
-            **When to keep both indexes:**
-            Only if the subset index is UNIQUE (which it isn't in this case), as unique 
-            constraints serve a different purpose than performance optimization.
-
-            Please remove the redundant subset index.
+                    message: utils_1.StringUtil.trim `
+            Inefficient subset index detected - superset index exists.
+
+            **What is a subset/superset index problem?**
+            In database indexing, when you have an index on (A, B, C), it can efficiently serve queries 
+            that filter by A, or by (A, B), or by (A, B, C). This is called index prefix matching.
+
+            **Current situation:**
+            - You have a plain index on: (${x.fieldNames.join(", ")})
+            - But there's already a plain index on its superset: (${y.fieldNames.join(", ")})
+            - The subset index is redundant because the superset can handle the same queries
+
+            **Why is this a problem?**
+            1. **Query efficiency**: The superset index can handle all queries the subset can
+            2. **Storage waste**: You're maintaining two indexes where one would suffice
+            3. **Write performance**: Each index slows down INSERT, UPDATE, and DELETE operations
+            4. **Maintenance overhead**: More indexes mean more work for the database
+
+            **How indexes work (example):**
+            If you have an index on (country, city, street):
+            - ✅ Can efficiently find by country
+            - ✅ Can efficiently find by country + city
+            - ✅ Can efficiently find by country + city + street
+            - ❌ Cannot efficiently find by city alone
+            - ❌ Cannot efficiently find by street alone
+
+            **How to fix:**
+            Remove the subset index (${x.fieldNames.join(", ")}) because:
+            - The superset index (${y.fieldNames.join(", ")}) already covers these queries
+            - You'll save storage space and improve write performance
+            - Query performance will remain the same
+
+            **When to keep both indexes:**
+            Only if the subset index is UNIQUE (which it isn't in this case), as unique 
+            constraints serve a different purpose than performance optimization.
+
+            Please remove the redundant subset index.
           `,
                 });
         });
@@ -346,12 +346,12 @@ function validateDuplicatedIndexes(model, accessor) {
             path: `${accessor}.ginIndexes`,
             table: model.name,
             field: null,
-            message: utils_1.StringUtil.trim `
-        Duplicated GIN index found.
-        
-        GIN index can only be used once per field.
-
-        Please remove the duplicated GIN indexes.
+            message: utils_1.StringUtil.trim `
+        Duplicated GIN index found.
+        
+        GIN index can only be used once per field.
+
+        Please remove the duplicated GIN indexes.
       `,
         });
     return errors;
@@ -387,24 +387,24 @@ function validateDuplicatedRelationOppositeNames(dict, model) {
                     path: `application.files[${c.fileIndex}].models[${c.modelIndex}].foreignFields[${item.foreignFieldIndex}].relation.oppositeName`,
                     table: c.model.name,
                     field: ff.name,
-                    message: utils_1.StringUtil.trim `
-            oppositeName "${oppositeName}" conflicts with existing field in target model "${model.name}".
-
-            **What happened?**
-            The oppositeName "${oppositeName}" would create a reverse relation property in "${model.name}",
-            but "${model.name}" already has a field or relation with that name.
-
-            **Why is this a problem?**
-            - Prisma cannot have two properties with the same name in a model
-            - This will cause Prisma schema compilation errors
-            - The reverse relation would overwrite or conflict with the existing field
-
-            **How to fix:**
-            Choose a different oppositeName that doesn't conflict with existing fields in "${model.name}".
-
-            **Naming suggestions:**
-            - Add a descriptive prefix/suffix: "${oppositeName}List", "${oppositeName}Items", "related${oppositeName.charAt(0).toUpperCase() + oppositeName.slice(1)}"
-            - Use the source model name: "${c.model.name.replace(/_/g, "").toLowerCase()}s"
+                    message: utils_1.StringUtil.trim `
+            oppositeName "${oppositeName}" conflicts with existing field in target model "${model.name}".
+
+            **What happened?**
+            The oppositeName "${oppositeName}" would create a reverse relation property in "${model.name}",
+            but "${model.name}" already has a field or relation with that name.
+
+            **Why is this a problem?**
+            - Prisma cannot have two properties with the same name in a model
+            - This will cause Prisma schema compilation errors
+            - The reverse relation would overwrite or conflict with the existing field
+
+            **How to fix:**
+            Choose a different oppositeName that doesn't conflict with existing fields in "${model.name}".
+
+            **Naming suggestions:**
+            - Add a descriptive prefix/suffix: "${oppositeName}List", "${oppositeName}Items", "related${oppositeName.charAt(0).toUpperCase() + oppositeName.slice(1)}"
+            - Use the source model name: "${c.model.name.replace(/_/g, "").toLowerCase()}s"
           `,
                 });
             });
@@ -421,41 +421,41 @@ function validateDuplicatedRelationOppositeNames(dict, model) {
                 path: `application.files[${c.fileIndex}].models[${c.modelIndex}].foreignFields[${item.foreignFieldIndex}].relation.oppositeName`,
                 table: c.model.name,
                 field: ff.name,
-                message: utils_1.StringUtil.trim `
-          Duplicated relation oppositeName "${oppositeName}" detected on target model "${model.name}".
-
-          **What is oppositeName?**
-          In Prisma relations, oppositeName defines the name of the reverse relation field
-          on the target model. It allows the target model to access related records through
-          this named property.
-
-          **Current situation:**
-          Multiple foreign key fields from different models are trying to create reverse
-          relations on "${model.name}" with the same oppositeName "${oppositeName}".
-
-          **Conflicting relations:**
+                message: utils_1.StringUtil.trim `
+          Duplicated relation oppositeName "${oppositeName}" detected on target model "${model.name}".
+
+          **What is oppositeName?**
+          In Prisma relations, oppositeName defines the name of the reverse relation field
+          on the target model. It allows the target model to access related records through
+          this named property.
+
+          **Current situation:**
+          Multiple foreign key fields from different models are trying to create reverse
+          relations on "${model.name}" with the same oppositeName "${oppositeName}".
+
+          **Conflicting relations:**
           ${array
                     .filter((_, j) => i !== j)
                     .map((oppo) => `- Model "${oppo.container.model.name}", field "${oppo.foreignField.name}" (accessor: application.files[${oppo.container.fileIndex}].models[${oppo.container.modelIndex}].foreignFields[${oppo.foreignFieldIndex}].relation.oppositeName)`)
-                    .join("\n")}
-
-          **Why is this a problem?**
-          - Prisma requires unique relation names within a model
-          - When "${model.name}" tries to access related records, it won't know which relation to use
-          - This will cause Prisma schema compilation errors
-
-          **How to fix:**
-          Each relation pointing to "${model.name}" must have a unique oppositeName.
-
-          **Naming suggestions:**
-          - Use descriptive names that indicate the relationship's purpose
-          - Include the source model name for clarity
-          - Examples:
-            - Instead of both using "orders", use "customerOrders" and "sellerOrders"
-            - Instead of both using "users", use "createdByUser" and "assignedToUser"
-            - For "${c.model.name}" → "${model.name}": consider "${c.model.name.charAt(0).toLowerCase() + c.model.name.slice(1)}s" or a more descriptive name
-
-          Please rename the oppositeName to be unique across all relations targeting "${model.name}".
+                    .join("\n")}
+
+          **Why is this a problem?**
+          - Prisma requires unique relation names within a model
+          - When "${model.name}" tries to access related records, it won't know which relation to use
+          - This will cause Prisma schema compilation errors
+
+          **How to fix:**
+          Each relation pointing to "${model.name}" must have a unique oppositeName.
+
+          **Naming suggestions:**
+          - Use descriptive names that indicate the relationship's purpose
+          - Include the source model name for clarity
+          - Examples:
+            - Instead of both using "orders", use "customerOrders" and "sellerOrders"
+            - Instead of both using "users", use "createdByUser" and "assignedToUser"
+            - For "${c.model.name}" → "${model.name}": consider "${c.model.name.charAt(0).toLowerCase() + c.model.name.slice(1)}s" or a more descriptive name
+
+          Please rename the oppositeName to be unique across all relations targeting "${model.name}".
         `,
             });
         });
@@ -473,8 +473,8 @@ function validateValidNames(model, accessor) {
                 path: props.accessor,
                 table: model.name,
                 field: props.field,
-                message: utils_1.StringUtil.trim `
-        The name "${props.value}" is a system reserved keyword and cannot be used.
+                message: utils_1.StringUtil.trim `
+        The name "${props.value}" is a system reserved keyword and cannot be used.
       `,
             });
         else if (utils_1.AutoBeEscaper.variable(props.value) === false)
@@ -482,10 +482,10 @@ function validateValidNames(model, accessor) {
                 path: props.accessor,
                 table: model.name,
                 field: props.field,
-                message: utils_1.StringUtil.trim `
-        The name "${props.value}" is not a valid identifier.
-
-        Change to a valid identifier which can be a variable name in programming languages.
+                message: utils_1.StringUtil.trim `
+        The name "${props.value}" is not a valid identifier.
+
+        Change to a valid identifier which can be a variable name in programming languages.
       `,
             });
     };
@@ -584,38 +584,38 @@ function validateIndexes(model, accessor) {
                     path: `${accessor}.ginIndexes[${i}].fieldName`,
                     table: model.name,
                     field: null,
-                    message: utils_1.StringUtil.trim `
-            GIN index cannot be applied to this field.
-
-            **What is a GIN index?**
-            GIN (Generalized Inverted Index) is a special index type in PostgreSQL designed for 
-            full-text search and operations on complex data types. In AutoBE, GIN indexes are 
-            used exclusively for string fields to enable efficient text searching.
-
-            **Current problem:**
-            The field "${gin.fieldName}" specified for GIN index does not exist in the plain fields 
-            of model "${model.name}".
-
-            **Possible causes:**
-            1. The field name is misspelled
-            2. The field is a foreign key field (not a plain field)
-            3. The field was removed but the index definition remained
-
-            **How to fix:**
-            1. Check if the field name is correct
-            2. Ensure the field exists in the plainFields array
-            3. Make sure the field is of type "string" (GIN indexes only work with strings)
-            4. If the field doesn't exist, either:
-               - Add the missing string field to plainFields
-               - Remove this GIN index definition
-
-            **Example of correct GIN index usage:**
-            plainFields: [
-              { name: "content", type: "string" }  // ✓ Can use GIN index
-            ]
-            ginIndexes: [
-              { fieldName: "content" }  // ✓ Correct
-            ]
+                    message: utils_1.StringUtil.trim `
+            GIN index cannot be applied to this field.
+
+            **What is a GIN index?**
+            GIN (Generalized Inverted Index) is a special index type in PostgreSQL designed for 
+            full-text search and operations on complex data types. In AutoBE, GIN indexes are 
+            used exclusively for string fields to enable efficient text searching.
+
+            **Current problem:**
+            The field "${gin.fieldName}" specified for GIN index does not exist in the plain fields 
+            of model "${model.name}".
+
+            **Possible causes:**
+            1. The field name is misspelled
+            2. The field is a foreign key field (not a plain field)
+            3. The field was removed but the index definition remained
+
+            **How to fix:**
+            1. Check if the field name is correct
+            2. Ensure the field exists in the plainFields array
+            3. Make sure the field is of type "string" (GIN indexes only work with strings)
+            4. If the field doesn't exist, either:
+               - Add the missing string field to plainFields
+               - Remove this GIN index definition
+
+            **Example of correct GIN index usage:**
+            plainFields: [
+              { name: "content", type: "string" }  // ✓ Can use GIN index
+            ]
+            ginIndexes: [
+              { fieldName: "content" }  // ✓ Correct
+            ]
           `,
                 });
             else if (model.plainFields[pIndex].type !== "string")
@@ -623,44 +623,44 @@ function validateIndexes(model, accessor) {
                     path: `${accessor}.ginIndexes[${i}].fieldName`,
                     table: model.name,
                     field: model.plainFields[pIndex].name,
-                    message: utils_1.StringUtil.trim `
-            GIN index type mismatch - requires string field.
-
-            **What is a GIN index?**
-            GIN (Generalized Inverted Index) is PostgreSQL's specialized index for full-text search.
-            It's designed to efficiently search within text content, making it perfect for features like:
-            - Search functionality in articles or posts
-            - Finding keywords in product descriptions
-            - Filtering by text content
-
-            **Current problem:**
-            You're trying to apply a GIN index to field "${gin.fieldName}" which is of type "${model.plainFields[pIndex].type}".
-            GIN indexes can ONLY be applied to "string" type fields.
-
-            **Why string fields only?**
-            GIN indexes work by breaking down text into searchable tokens (words, phrases).
-            Other data types like numbers, booleans, or dates don't have this text structure.
-
-            **How to fix:**
-
-            1. **If you need text search on this field:**
-               - Change the field type to "string"
-               - Example: If storing a product code as number, consider storing as string instead
-
-            2. **If the field should remain as ${model.plainFields[pIndex].type}:**
-               - Remove the GIN index for this field
-               - Use a regular index instead (plainIndexes)
-               - Consider if you really need an index on this field
-
-            3. **Alternative indexing strategies:**
-               - For ${model.plainFields[pIndex].type} fields, use plainIndexes for general performance
-               - For unique ${model.plainFields[pIndex].type} values, use uniqueIndexes
-               - GIN indexes should be reserved for text search scenarios only
-
-            **Location of the field:**
-            - Field definition: ${`${accessor}.plainFields[${pIndex}]`}
-
-            Please either change the field type to "string" or remove the GIN index.
+                    message: utils_1.StringUtil.trim `
+            GIN index type mismatch - requires string field.
+
+            **What is a GIN index?**
+            GIN (Generalized Inverted Index) is PostgreSQL's specialized index for full-text search.
+            It's designed to efficiently search within text content, making it perfect for features like:
+            - Search functionality in articles or posts
+            - Finding keywords in product descriptions
+            - Filtering by text content
+
+            **Current problem:**
+            You're trying to apply a GIN index to field "${gin.fieldName}" which is of type "${model.plainFields[pIndex].type}".
+            GIN indexes can ONLY be applied to "string" type fields.
+
+            **Why string fields only?**
+            GIN indexes work by breaking down text into searchable tokens (words, phrases).
+            Other data types like numbers, booleans, or dates don't have this text structure.
+
+            **How to fix:**
+
+            1. **If you need text search on this field:**
+               - Change the field type to "string"
+               - Example: If storing a product code as number, consider storing as string instead
+
+            2. **If the field should remain as ${model.plainFields[pIndex].type}:**
+               - Remove the GIN index for this field
+               - Use a regular index instead (plainIndexes)
+               - Consider if you really need an index on this field
+
+            3. **Alternative indexing strategies:**
+               - For ${model.plainFields[pIndex].type} fields, use plainIndexes for general performance
+               - For unique ${model.plainFields[pIndex].type} values, use uniqueIndexes
+               - GIN indexes should be reserved for text search scenarios only
+
+            **Location of the field:**
+            - Field definition: ${`${accessor}.plainFields[${pIndex}]`}
+
+            Please either change the field type to "string" or remove the GIN index.
           `,
                 });
         },
@@ -689,53 +689,53 @@ function validateReferences(model, accessor, dict) {
                         path: `${accessor}.foreignFields[${i}].relation.targetModel`,
                         table: model.name,
                         field: field.name,
-                        message: utils_1.StringUtil.trim `
-              Cross-reference dependency detected between models.
-
-              **What is Cross-reference dependency?**
-              A cross-reference dependency (also known as circular dependency) occurs when two models 
-              reference each other through foreign key fields. This creates a circular relationship 
-              where Model A references Model B, and Model B also references Model A.
-
-              **Current situation:**
-              - ${model.name} model has a foreign key field "${field.name}" that references ${field.relation.targetModel}
-              - ${field.relation.targetModel} model also has a foreign key field that references ${model.name}
-              - Location of opposite reference: application.files[${target.fileIndex}].models[${target.modelIndex}].foreignFields[${j}].relation.targetModel
-
-              **Why is this a problem?**
-              Circular dependencies can cause issues with:
-              - Database initialization (which table to create first?)
-              - Data insertion (which record to insert first?)
-              - Cascading updates and deletes
-              - Query performance and complexity
-
-              **How to fix this:**
-              You need to remove one of the foreign key relationships. Here's how to decide:
-
-              1. **Identify the primary relationship direction**
-                 - Which model is the "parent" and which is the "child"?
-                 - Which relationship is essential for your business logic?
-                 - Example: In User ↔ Profile, User is typically the parent
-
-              2. **Remove the redundant foreign key**
-                 - Keep the foreign key in the child model pointing to the parent
-                 - Remove the foreign key in the parent model pointing to the child
-                 - You can still access the reverse relationship through Prisma's implicit relations
-
-              3. **Update any affected indexes**
-                 - Remove indexes that include the deleted foreign key field
-                 - Update composite indexes if necessary
-
-              **Example solution:**
-              If you have:
-              - User model with profileId foreign key
-              - Profile model with userId foreign key
-              
-              You should:
-              - Keep userId in Profile (child references parent)
-              - Remove profileId from User
-              - Access user's profile through: user.profile (Prisma will handle this)
-
+                        message: utils_1.StringUtil.trim `
+              Cross-reference dependency detected between models.
+
+              **What is Cross-reference dependency?**
+              A cross-reference dependency (also known as circular dependency) occurs when two models 
+              reference each other through foreign key fields. This creates a circular relationship 
+              where Model A references Model B, and Model B also references Model A.
+
+              **Current situation:**
+              - ${model.name} model has a foreign key field "${field.name}" that references ${field.relation.targetModel}
+              - ${field.relation.targetModel} model also has a foreign key field that references ${model.name}
+              - Location of opposite reference: application.files[${target.fileIndex}].models[${target.modelIndex}].foreignFields[${j}].relation.targetModel
+
+              **Why is this a problem?**
+              Circular dependencies can cause issues with:
+              - Database initialization (which table to create first?)
+              - Data insertion (which record to insert first?)
+              - Cascading updates and deletes
+              - Query performance and complexity
+
+              **How to fix this:**
+              You need to remove one of the foreign key relationships. Here's how to decide:
+
+              1. **Identify the primary relationship direction**
+                 - Which model is the "parent" and which is the "child"?
+                 - Which relationship is essential for your business logic?
+                 - Example: In User ↔ Profile, User is typically the parent
+
+              2. **Remove the redundant foreign key**
+                 - Keep the foreign key in the child model pointing to the parent
+                 - Remove the foreign key in the parent model pointing to the child
+                 - You can still access the reverse relationship through Prisma's implicit relations
+
+              3. **Update any affected indexes**
+                 - Remove indexes that include the deleted foreign key field
+                 - Update composite indexes if necessary
+
+              **Example solution:**
+              If you have:
+              - User model with profileId foreign key
+              - Profile model with userId foreign key
+              
+              You should:
+              - Keep userId in Profile (child references parent)
+              - Remove profileId from User
+              - Access user's profile through: user.profile (Prisma will handle this)
+
               Please eliminate the circular dependency and regenerate the schema.`,
                     });
                 }