database/schema/processors/sqlserver.go (2)

19-19: Consider using pointer receivers for consistency

The method ProcessColumns uses a value receiver (r Sqlserver). To maintain consistency and avoid unnecessary copies, consider changing the receiver to a pointer (r *Sqlserver).

---

54-54: Ensure consistent use of receivers

The method ProcessIndexes uses a value receiver (r Sqlserver). For consistency and to avoid unnecessary copying of the struct, consider changing it to a pointer receiver (r *Sqlserver).

database/schema/processors/postgres.go (2)

19-19: Consider using pointer receivers for consistency

The method ProcessColumns uses a value receiver (r Postgres). To maintain consistency and improve performance, consider changing the receiver to a pointer (r *Postgres).

---

68-68: Ensure consistent use of receivers

The method ProcessIndexes uses a value receiver (r Postgres). For consistency and efficiency, consider changing it to a pointer receiver (r *Postgres).

database/schema/schema.go (2)

31-32: Group related struct fields together

The newly added fields processor and schema are placed after other fields. For improved readability, consider grouping related fields together within the Schema struct.

---

135-144: Enhance error handling in GetForeignKeys

The GetForeignKeys method could benefit from enhanced error handling. Consider wrapping errors with more context or logging errors to aid in debugging if issues arise during foreign key retrieval.

database/schema/grammars/sqlite_test.go (2)

10-11: Organize import statements

Consider grouping the imports to enhance readability and maintain consistency with the rest of the codebase.

---

160-272: Improve test structure in TestCompileRenameIndex

The TestCompileRenameIndex function contains several subtests. Consider using s.Run within each subtest for better isolation and clearer test output.

database/schema/grammars/sqlite.go (2)

10-11: Organize imports for clarity

Group the import statements to enhance readability and maintain consistency.

---

179-219: Refactor complex logic in CompileRenameIndex

The method CompileRenameIndex contains complex conditional logic and relies on logging warnings. Consider refactoring to simplify the logic, improve readability, and ensure all scenarios are properly handled and tested.

database/schema/grammars/mysql.go (3)

Line range hint 284-299: Optimize type assertions in ModifyOnUpdate method

There are redundant type assertions for onUpdate. Refactor the switch statement to eliminate unnecessary assertions and improve readability.

Suggested refactor:

func (r *Mysql) ModifyOnUpdate(_ schema.Blueprint, column schema.ColumnDefinition) string {
	onUpdate := column.GetOnUpdate()
	if onUpdate != nil {
		switch value := onUpdate.(type) {
		case Expression:
			return " on update " + string(value)
		case string:
			if value != "" {
				return " on update " + value
			}
		}
	}

	return ""
}

---

300-302: Remove unused parameter name in TypeBigInteger method

The parameter name is unnecessary since it's not used within the method. Removing it improves code clarity.

Suggested change:

-func (r *Mysql) TypeBigInteger(_ schema.ColumnDefinition) string {
+func (r *Mysql) TypeBigInteger(schema.ColumnDefinition) string {
	return "bigint"
}

---

442-454: Ensure compileKey method promotes code reuse

The compileKey method is designed for reuse in key compilation. Verify that it's utilized effectively in methods like CompileUnique and CompileFullText to reduce code duplication.

database/schema/grammars/sqlserver.go (1)

115-126: Address the TODO in CompileDropDefaultConstraint method

There's a TODO comment indicating additional logic is needed. Implement the required logic or provide an explanation if it's intentionally left unimplemented.

Do you need assistance in implementing the logic for dropping default constraints?

database/schema/schema_test.go (2)

135-153: Consider renaming TestColumnMethods for clarity

The test seems to focus on dropping columns rather than general column methods. Renaming it to reflect its purpose would improve readability.

---

1451-1480: Enhance TestFullText to handle driver differences

The TestFullText method has conditional assertions based on the driver. Consider expanding the tests to handle and document the behavior for drivers that do not support full-text indexing.

database/schema/processors/utils.go (1)

Line range hint 9-19: LGTM with a suggestion for error handling.

The type change and index processing logic look good. However, consider adding validation for empty column strings to prevent potential issues with the strings.Split operation.

Consider adding this validation:

 func processIndexes(dbIndexes []schema.DBIndex) []schema.Index {
 	var indexes []schema.Index
 	for _, dbIndex := range dbIndexes {
+		if dbIndex.Columns == "" {
+			continue
+		}
 		indexes = append(indexes, schema.Index{
 			Columns: strings.Split(dbIndex.Columns, ","),
 			Name:    strings.ToLower(dbIndex.Name),

database/schema/constants/constants.go (1)

7-20: LGTM with a documentation suggestion.

The new constants follow a consistent naming pattern and provide comprehensive coverage for index operations. Consider adding documentation comments for each constant group to explain their purpose and usage.

Consider adding documentation like this:

 const (
+	// Table operations
 	CommandAdd          = "add"
 	CommandComment      = "comment"
 	CommandCreate       = "create"
 	CommandDrop         = "drop"
+
+	// Column and index operations
 	CommandDropColumn   = "dropColumn"
 	CommandDropForeign  = "dropForeign"
 	CommandDropFullText = "dropFullText"

database/schema/processors/utils_test.go (1)

Line range hint 13-31: Consider enhancing test coverage with additional cases.

While the current tests cover basic functionality, consider adding more test cases using a table-driven approach to improve coverage.

Consider refactoring the tests like this:

 func TestProcessIndexes(t *testing.T) {
-	// Test with valid indexes
-	input := []schema.DBIndex{
-		{Name: "INDEX_A", Type: "BTREE", Columns: "a,b"},
-		{Name: "INDEX_B", Type: "HASH", Columns: "c,d"},
-	}
-	expected := []schema.Index{
-		{Name: "index_a", Type: "btree", Columns: []string{"a", "b"}},
-		{Name: "index_b", Type: "hash", Columns: []string{"c", "d"}},
-	}
-
-	result := processIndexes(input)
-
-	assert.Equal(t, expected, result)
-
-	// Test with empty input
-	input = []schema.DBIndex{}
-
-	result = processIndexes(input)
-
-	assert.Nil(t, result)
+	tests := []struct {
+		name     string
+		input    []schema.DBIndex
+		expected []schema.Index
+	}{
+		{
+			name: "valid indexes",
+			input: []schema.DBIndex{
+				{Name: "INDEX_A", Type: "BTREE", Columns: "a,b"},
+				{Name: "INDEX_B", Type: "HASH", Columns: "c,d"},
+			},
+			expected: []schema.Index{
+				{Name: "index_a", Type: "btree", Columns: []string{"a", "b"}},
+				{Name: "index_b", Type: "hash", Columns: []string{"c", "d"}},
+			},
+		},
+		{
+			name:     "empty input",
+			input:    []schema.DBIndex{},
+			expected: nil,
+		},
+		{
+			name: "empty columns",
+			input: []schema.DBIndex{
+				{Name: "INDEX_A", Type: "BTREE", Columns: ""},
+			},
+			expected: []schema.Index{},
+		},
+	}
+
+	for _, tt := range tests {
+		t.Run(tt.name, func(t *testing.T) {
+			result := processIndexes(tt.input)
+			assert.Equal(t, tt.expected, result)
+		})
+	}
 }

contracts/database/schema/index.go (1)

18-20: Consider documenting PostgreSQL-specific features

The new methods Deferrable() and InitiallyImmediate() appear to be PostgreSQL-specific features for constraint management. Consider adding documentation to clarify their intended use and database compatibility.

database/schema/processors/mysql.go (1)

60-62: Document the processIndexes helper function

The ProcessIndexes method delegates to a helper function processIndexes. Consider adding documentation to explain this shared functionality.

database/schema/processors/sqlite.go (1)

35-49: Consider adding validation for foreign key actions and column names

While the implementation is generally sound, consider these improvements:

1. Validate OnUpdate/OnDelete actions against allowed values (RESTRICT, CASCADE, SET NULL, etc.)
2. Consider using a more robust column splitting mechanism in case column names contain commas

Here's a suggested improvement:

 func (r Sqlite) ProcessForeignKeys(dbForeignKeys []schema.DBForeignKey) []schema.ForeignKey {
+	// Define allowed actions
+	allowedActions := map[string]bool{
+		"restrict":   true,
+		"cascade":    true,
+		"set null":   true,
+		"no action":  true,
+	}
+
 	var foreignKeys []schema.ForeignKey
 	for _, dbForeignKey := range dbForeignKeys {
+		onUpdate := strings.ToLower(dbForeignKey.OnUpdate)
+		onDelete := strings.ToLower(dbForeignKey.OnDelete)
+		
+		// Validate actions
+		if onUpdate != "" && !allowedActions[onUpdate] {
+			onUpdate = "restrict" // default to restrict if invalid
+		}
+		if onDelete != "" && !allowedActions[onDelete] {
+			onDelete = "restrict" // default to restrict if invalid
+		}
+
 		foreignKeys = append(foreignKeys, schema.ForeignKey{
 			Name:           dbForeignKey.Name,
 			Columns:        strings.Split(dbForeignKey.Columns, ","),
 			ForeignTable:   dbForeignKey.ForeignTable,
 			ForeignColumns: strings.Split(dbForeignKey.ForeignColumns, ","),
-			OnUpdate:       strings.ToLower(dbForeignKey.OnUpdate),
-			OnDelete:       strings.ToLower(dbForeignKey.OnDelete),
+			OnUpdate:       onUpdate,
+			OnDelete:       onDelete,
 		})
 	}

database/schema/index.go (1)

94-110: Consider database compatibility documentation for new index features

The new methods (Deferrable, InitiallyImmediate, Language) appear to be PostgreSQL-specific features. Consider adding documentation comments to clarify database compatibility.

Example documentation:

+// Deferrable sets the index to be deferrable. This is only supported in PostgreSQL.
 func (r *IndexDefinition) Deferrable() schema.IndexDefinition {
     r.command.Deferrable = convert.Pointer(true)
     return r
 }

+// InitiallyImmediate sets the deferrable index to be initially immediate. This is only supported in PostgreSQL.
 func (r *IndexDefinition) InitiallyImmediate() schema.IndexDefinition {
     r.command.InitiallyImmediate = convert.Pointer(true)
     return r
 }

+// Language sets the index language. This is only supported in PostgreSQL for full-text search indexes.
 func (r *IndexDefinition) Language(name string) schema.IndexDefinition {
     r.command.Language = name
     return r
 }

database/schema/grammars/wrap.go (1)

46-54: Consider optimizing PrefixArray for large slices

While the current implementation using collect.Map is clean, for large slices, it might be more efficient to use a pre-allocated slice with direct assignment.

Consider this alternative implementation:

 func (r *Wrap) PrefixArray(prefix string, values []string) []string {
-    return collect.Map(values, func(value string, _ int) string {
-        return prefix + " " + value
-    })
+    result := make([]string, len(values))
+    for i, value := range values {
+        result[i] = prefix + " " + value
+    }
+    return result
 }

database/schema/processors/mysql_test.go (1)

73-99: Enhance foreign key test coverage

While the basic test cases are good, consider adding more test scenarios:

1. Multiple foreign keys on a table
2. Foreign keys with multiple columns
3. Edge cases for ON UPDATE/DELETE actions (RESTRICT, NO ACTION)

Example additional test case:

 tests := []struct {
   name          string
   dbForeignKeys []schema.DBForeignKey
   expected      []schema.ForeignKey
 }{
+  {
+    name: "MultipleColumnsFK",
+    dbForeignKeys: []schema.DBForeignKey{
+      {
+        Name: "fk_composite",
+        Columns: "tenant_id,user_id",
+        ForeignSchema: "public",
+        ForeignTable: "tenants_users",
+        ForeignColumns: "tenant_id,user_id",
+        OnUpdate: "RESTRICT",
+        OnDelete: "NO ACTION",
+      },
+    },
+    expected: []schema.ForeignKey{
+      {
+        Name: "fk_composite",
+        Columns: []string{"tenant_id", "user_id"},
+        ForeignSchema: "public",
+        ForeignTable: "tenants_users",
+        ForeignColumns: []string{"tenant_id", "user_id"},
+        OnUpdate: "restrict",
+        OnDelete: "no action",
+      },
+    },
+  },

database/schema/postgres_schema.go (1)

Line range hint 148-152: Consider error wrapping for better context

When scanning query results, consider wrapping errors with additional context to aid debugging.

 var dbIndexes []contractsschema.DBIndex
-if err := r.orm.Query().Raw(r.grammar.CompileIndexes(schema, table)).Scan(&dbIndexes); err != nil {
+if err := r.orm.Query().Raw(r.grammar.CompileIndexes(schema, table)).Scan(&dbIndexes); err != nil {
+	return nil, fmt.Errorf("failed to scan indexes for table %s.%s: %w", schema, table, err)
+}

database/schema/processors/sqlite_test.go (2)

Line range hint 24-72: Consider adding edge cases to strengthen test coverage.

The test cases are well-structured, but consider adding these scenarios:

• Column with maximum length values
• Column with special characters in name
• Column with empty/null default values

---

Line range hint 104-143: Refactor test structure to use table-driven tests consistently.

Instead of separate test sections with comments, consider using a table-driven approach similar to other tests:

-	// Test with valid indexes
-	input := []schema.DBIndex{
+	tests := []struct {
+		name     string
+		input    []schema.DBIndex
+		expected []schema.Index
+	}{
+		{
+			name: "ValidIndexes",
+			input: []schema.DBIndex{
+				{Name: "INDEX_A", Type: "BTREE", Columns: "a,b"},
+				{Name: "INDEX_B", Type: "HASH", Columns: "c,d"},
+				{Name: "INDEX_C", Type: "HASH", Columns: "e,f", Primary: true},
+			},
+			expected: []schema.Index{
+				{Name: "index_a", Columns: []string{"a", "b"}},
+				{Name: "index_b", Columns: []string{"c", "d"}},
+				{Name: "index_c", Columns: []string{"e", "f"}, Primary: true},
+			},
+		},
+		// Add more test cases here
+	}
+
+	for _, tt := range tests {
+		s.Run(tt.name, func() {
+			result := sqlite.ProcessIndexes(tt.input)
+			s.Equal(tt.expected, result)
+		})
+	}

database/schema/processors/postgres_test.go (2)

Line range hint 24-72: Add PostgreSQL-specific column type test cases.

Consider adding test cases for PostgreSQL-specific features:

• Array types
• JSON/JSONB types
• Custom types/domains
• Interval types

---

Line range hint 103-151: Standardize test structure using table-driven tests.

Similar to the suggestion for SQLite tests, consider refactoring to use a consistent table-driven approach:

-	// ValidTypes_ReturnsProcessedTypes
-	input := []schema.Type{
+	tests := []struct {
+		name     string
+		input    []schema.Type
+		expected []schema.Type
+	}{
+		{
+			name: "ValidTypes",
+			input: []schema.Type{
+				{Type: "b", Category: "a"},
+				{Type: "c", Category: "b"},
+				{Type: "d", Category: "c"},
+			},
+			expected: []schema.Type{
+				{Type: "base", Category: "array"},
+				{Type: "composite", Category: "boolean"},
+				{Type: "domain", Category: "composite"},
+			},
+		},
+		// Add more test cases here
+	}
+
+	for _, tt := range tests {
+		s.Run(tt.name, func() {
+			result := postgres.ProcessTypes(tt.input)
+			s.Equal(tt.expected, result)
+		})
+	}

database/schema/processors/sqlserver_test.go (1)

Line range hint 21-103: Standardize SQL Server instance creation across tests.

Currently, some tests use the instance from SetupTest while others create new instances. Standardize by using the suite's instance consistently:

-	sqlserver := NewSqlserver()
-	for _, tt := range tests {
+	for _, tt := range tests {
 		s.Run(tt.name, func() {
-			result := sqlserver.ProcessColumns(tt.dbColumns)
+			result := s.sqlserver.ProcessColumns(tt.dbColumns)
 			s.Equal(tt.expected, result)
 		})
 	}

contracts/database/schema/grammar.go (1)

22-35: Consider adding validation parameters for drop operations

The drop operations (DropColumn, DropForeign, DropFullText, DropIndex, DropPrimary, DropUnique) should include validation to prevent accidental drops of critical schema elements.

Consider adding a force parameter or implementing a validation mechanism in the grammar implementations to confirm these destructive operations, especially for production environments.

contracts/database/schema/blueprint.go (2)

28-31: Consider adding safety checks for drop operations

The Drop and DropColumn operations are destructive. Consider adding mechanisms to:

1. Verify the existence of tables/columns before dropping
2. Implement a dry-run option
3. Add backup capabilities

---

48-57: Consider grouping related drop operations

The drop operations for timestamps and soft deletes could be grouped into a more generic method to improve maintainability.

Consider something like:

+// DropColumns Drop multiple columns with a specific type
+DropColumns(columnType string, columns ...string)

database/schema/grammars/sqlserver_test.go (1)

85-92: Consider adding more test cases for edge scenarios.

While the test covers the basic functionality of dropping multiple columns, consider adding test cases for:

1. Dropping a single column
2. Handling non-existent columns
3. Case sensitivity in column names

Here's a suggested expansion of the test:

 func (s *SqlserverSuite) TestCompileDropColumn() {
     mockBlueprint := mocksschema.NewBlueprint(s.T())
-    mockBlueprint.EXPECT().GetTableName().Return("users").Twice()
+    tests := []struct {
+        name      string
+        columns   []string
+        tableName string
+        expected  []string
+    }{
+        {
+            name:      "multiple columns",
+            columns:   []string{"id", "name"},
+            tableName: "users",
+            expected:  []string{`DECLARE @sql NVARCHAR(MAX) = '';SELECT @sql += 'ALTER TABLE $table DROP CONSTRAINT ' + OBJECT_NAME([default_object_id]) + ';' FROM sys.columns WHERE [object_id] = OBJECT_ID('"goravel_users"') AND [name] in ("id", "name") AND [default_object_id] <> 0;EXEC(@sql); alter table "goravel_users" drop column "id", "name"`},
+        },
+        {
+            name:      "single column",
+            columns:   []string{"id"},
+            tableName: "users",
+            expected:  []string{`DECLARE @sql NVARCHAR(MAX) = '';SELECT @sql += 'ALTER TABLE $table DROP CONSTRAINT ' + OBJECT_NAME([default_object_id]) + ';' FROM sys.columns WHERE [object_id] = OBJECT_ID('"goravel_users"') AND [name] in ("id") AND [default_object_id] <> 0;EXEC(@sql); alter table "goravel_users" drop column "id"`},
+        },
+    }
 
-    s.Equal([]string{`DECLARE @sql NVARCHAR(MAX) = '';SELECT @sql += 'ALTER TABLE $table DROP CONSTRAINT ' + OBJECT_NAME([default_object_id]) + ';' FROM sys.columns WHERE [object_id] = OBJECT_ID('"goravel_users"') AND [name] in ("id", "name") AND [default_object_id] <> 0;EXEC(@sql); alter table "goravel_users" drop column "id", "name"`}, s.grammar.CompileDropColumn(mockBlueprint, &contractsschema.Command{
-        Columns: []string{"id", "name"},
-    }))
+    for _, test := range tests {
+        s.Run(test.name, func() {
+            mockBlueprint.EXPECT().GetTableName().Return(test.tableName).Twice()
+            result := s.grammar.CompileDropColumn(mockBlueprint, &contractsschema.Command{
+                Columns: test.columns,
+            })
+            s.Equal(test.expected, result)
+        })
+    }
 }

database/schema/grammars/mysql_test.go (1)

108-117: Consider expanding test coverage for drop column scenarios.

Similar to the SQL Server tests, this test could benefit from additional test cases covering:

1. Single column drops
2. Error cases
3. Different table name formats

Here's a suggested expansion:

 func (s *MysqlSuite) TestCompileDropColumn() {
-    mockBlueprint := mocksschema.NewBlueprint(s.T())
-    mockBlueprint.EXPECT().GetTableName().Return("users").Once()
-
-    s.Equal([]string{
-        "alter table `goravel_users` drop `id`, drop `name`",
-    }, s.grammar.CompileDropColumn(mockBlueprint, &contractsschema.Command{
-        Columns: []string{"id", "name"},
-    }))
+    tests := []struct {
+        name      string
+        tableName string
+        columns   []string
+        expected  []string
+    }{
+        {
+            name:      "multiple columns",
+            tableName: "users",
+            columns:   []string{"id", "name"},
+            expected:  []string{"alter table `goravel_users` drop `id`, drop `name`"},
+        },
+        {
+            name:      "single column",
+            tableName: "users",
+            columns:   []string{"id"},
+            expected:  []string{"alter table `goravel_users` drop `id`"},
+        },
+        {
+            name:      "table with schema",
+            tableName: "public.users",
+            columns:   []string{"id"},
+            expected:  []string{"alter table `public`.`goravel_users` drop `id`"},
+        },
+    }
+
+    for _, test := range tests {
+        s.Run(test.name, func() {
+            mockBlueprint := mocksschema.NewBlueprint(s.T())
+            mockBlueprint.EXPECT().GetTableName().Return(test.tableName).Once()
+            result := s.grammar.CompileDropColumn(mockBlueprint, &contractsschema.Command{
+                Columns: test.columns,
+            })
+            s.Equal(test.expected, result)
+        })
+    }
 }

database/schema/grammars/postgres_test.go (4)

119-126: Consider adding more test cases for CompileDropColumn

While the current test case covers dropping multiple columns, consider adding test cases for:

• Dropping a single column
• Edge cases like dropping columns with special characters or reserved keywords

---

135-140: Add error case handling for CompileDropPrimary

Consider adding test cases to verify behavior when:

• The table doesn't have a primary key
• The table name contains special characters

---

189-197: Add test cases for different language configurations in CompileFullText

The current test only covers the 'english' language configuration. Consider adding test cases for:

• Different language configurations
• Custom text search configurations
• Multiple columns with different weights

---

Line range hint 119-291: Improve test consistency and utilities

Consider the following improvements for better maintainability:

1. Use table-driven tests consistently across all test methods
2. Extract common mock setup into helper methods
3. Consider adding a test utility function for creating pointer values (used in deferrable/initially immediate flags)

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Check for any remaining references to processors.DBColumn/DBIndex
rg "processors\.(DBColumn|DBIndex)" -l

# Check for adoption of contractsschema.DBColumn/DBIndex
rg "contractsschema\.(DBColumn|DBIndex)" -l

#!/bin/bash
# Let's check the actual usage context in these files to ensure the migration is complete
rg "processors\.(DBColumn|DBIndex)" -A 2 -B 2
rg "contractsschema\.(DBColumn|DBIndex)" -A 2 -B 2

#!/bin/bash
# Check grammar implementation for escaping
rg -A 5 'func.*CompileColumns|func.*EscapeNames' --type go

#!/bin/bash
# Check wrap.Quote implementation and related escaping mechanisms
rg -A 5 'func.*Quote|func.*Escape' --type go

# Also check if there are any direct usages of these schema/table parameters
ast-grep --pattern 'CompileColumns($schema, $table)'

#!/bin/bash
# Get the full implementation of Postgres CompileColumns
rg -A 15 'func \(r \*Postgres\) CompileColumns' database/schema/grammars/postgres.go

# Also check if there's any specific table/schema name validation or sanitization
rg -A 5 'func.*ValidateTable|func.*ValidateSchema|func.*Sanitize' --type go

#!/bin/bash
# Check if these features are consistently implemented across different database processors
ast-grep --pattern 'func $_(b Blueprint, command *Command) string {
  $$$
  CompileFullText($$$)
  $$$
}'

#!/bin/bash
# Let's check for implementations of CompileFullText and CompileForeignKeys across different database processors
echo "=== Searching for CompileFullText implementations ==="
ast-grep --pattern 'func (p *$_) CompileFullText(blueprint Blueprint, command *Command) string {
  $$$
}'

echo -e "\n=== Searching for CompileForeignKeys implementations ==="
ast-grep --pattern 'func (p *$_) CompileForeignKeys(schema string, table string) string {
  $$$
}'

# Also check for any test files related to these features
echo -e "\n=== Searching for related test files ==="
fd -e go -E vendor . | grep -i "test" | xargs rg -l "CompileFullText|CompileForeignKeys"

#!/bin/bash
# Let's examine the postgres test file and check the actual implementations in the postgres grammar
echo "=== Checking postgres_test.go ==="
cat database/schema/grammars/postgres_test.go

echo -e "\n=== Checking postgres grammar implementation ==="
rg -A 5 "CompileFullText|CompileForeignKeys" database/schema/grammars/postgres.go

# Let's also check other database grammar implementations
echo -e "\n=== Checking other grammar implementations ==="
fd -e go -E vendor . | grep "grammars" | grep -v "test" | xargs rg -l "type.*Grammar"

#!/bin/bash
# Check implementation consistency across database processors
ast-grep --pattern 'func $_(b Blueprint, command *Command) string {
  $$$
  CompileUnique($$$)
  $$$
}'

#!/bin/bash
# Search for index-related operations in database implementations
rg -A 5 "RenameIndex|CompileRenameIndex" --type go

# Search for unique index operations
rg -A 5 "CompileUnique|CreateUnique" --type go

# Find all database processor implementations
fd -e go -E "test" . | rg "processor|grammar"

#!/bin/bash
# Description: Check NewBlueprint usage across the codebase to ensure consistent parameter usage

# Search for NewBlueprint calls
rg -A 2 'NewBlueprint\(' 

#!/bin/bash
# Check the actual implementation of NewBlueprint and its schema parameter usage
ast-grep --pattern 'func NewBlueprint($_, $_, $_, $_) $_'

#!/bin/bash
# Let's check the actual implementation with correct number of parameters
ast-grep --pattern 'func NewBlueprint($_, $_, $_) $_'

# Also get the implementation details
rg -A 5 '^func NewBlueprint'

database/schema/grammars/postgres_test.go (2)

119-126: Consider enhancing test coverage with edge cases

While the basic test case is good, consider adding more test cases using table-driven tests to cover:

• Single column drops
• Column names with special characters
• Schema-qualified tables

Here's a suggested refactor:

 func (s *PostgresSuite) TestCompileDropColumn() {
-	mockBlueprint := mocksschema.NewBlueprint(s.T())
-	mockBlueprint.EXPECT().GetTableName().Return("users").Once()
-
-	s.Equal([]string([]string{`alter table "goravel_users" drop column "id", drop column "email"`}), s.grammar.CompileDropColumn(mockBlueprint, &contractsschema.Command{
-		Columns: []string{"id", "email"},
-	}))
+	var mockBlueprint *mocksschema.Blueprint
+	
+	beforeEach := func() {
+		mockBlueprint = mocksschema.NewBlueprint(s.T())
+	}
+	
+	tests := []struct {
+		name      string
+		tableName string
+		columns   []string
+		expectSql []string
+	}{
+		{
+			name:      "multiple columns",
+			tableName: "users",
+			columns:   []string{"id", "email"},
+			expectSql: []string{`alter table "goravel_users" drop column "id", drop column "email"`},
+		},
+		{
+			name:      "single column",
+			tableName: "users",
+			columns:   []string{"id"},
+			expectSql: []string{`alter table "goravel_users" drop column "id"`},
+		},
+		{
+			name:      "schema qualified table",
+			tableName: "public.users",
+			columns:   []string{"id"},
+			expectSql: []string{`alter table "public"."goravel_users" drop column "id"`},
+		},
+	}
+	
+	for _, test := range tests {
+		s.Run(test.name, func() {
+			beforeEach()
+			mockBlueprint.EXPECT().GetTableName().Return(test.tableName).Once()
+			
+			sql := s.grammar.CompileDropColumn(mockBlueprint, &contractsschema.Command{
+				Columns: test.columns,
+			})
+			s.Equal(test.expectSql, sql)
+		})
+	}
 }

---

135-140: Consider adding test cases for schema-qualified tables

The test covers the basic case but could be enhanced to handle schema-qualified tables.

Here's a suggested refactor:

 func (s *PostgresSuite) TestCompileDropPrimary() {
-	mockBlueprint := mocksschema.NewBlueprint(s.T())
-	mockBlueprint.EXPECT().GetTableName().Return("users").Once()
-
-	s.Equal(`alter table "goravel_users" drop constraint "goravel_users_pkey"`, s.grammar.CompileDropPrimary(mockBlueprint, &contractsschema.Command{}))
+	var mockBlueprint *mocksschema.Blueprint
+	
+	beforeEach := func() {
+		mockBlueprint = mocksschema.NewBlueprint(s.T())
+	}
+	
+	tests := []struct {
+		name      string
+		tableName string
+		expectSql string
+	}{
+		{
+			name:      "simple table",
+			tableName: "users",
+			expectSql: `alter table "goravel_users" drop constraint "goravel_users_pkey"`,
+		},
+		{
+			name:      "schema qualified table",
+			tableName: "public.users",
+			expectSql: `alter table "public"."goravel_users" drop constraint "goravel_users_pkey"`,
+		},
+	}
+	
+	for _, test := range tests {
+		s.Run(test.name, func() {
+			beforeEach()
+			mockBlueprint.EXPECT().GetTableName().Return(test.tableName).Once()
+			
+			sql := s.grammar.CompileDropPrimary(mockBlueprint, &contractsschema.Command{})
+			s.Equal(test.expectSql, sql)
+		})
+	}
 }

Configuration used: CodeRabbit UI
Review profile: CHILL