feat(column-operations): add uppercase conversion functionality

[DaxServer]

This commit adds a new feature to the data processing component that allows users to convert the contents of a selected column to uppercase. The changes include:

• Implement the handleUpperCase function in the ColumnHeaderMenu.vue component to handle the uppercase conversion operation.
• Add a new test case in project.replace.test.ts to verify the basic find and replace functionality.
• Implement the UppercaseConversionService in uppercase-conversion.service.ts to handle the database operations for the uppercase conversion.
• Add a new test suite in uppercase.test.ts to cover the uppercase conversion API endpoint.

These changes provide users with an additional data transformation option, making the application more versatile and user-friendly.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Added “To uppercase” action in the column header menu to convert a selected column’s values to uppercase.
  • Displays success/warning messages and affected row counts after the operation.

• Refactor

  • Standardized success responses for data-processing operations to consistently return affected row counts.
  • Improved validation feedback with clearer errors for missing or invalid column inputs.

• Tests

  • Added comprehensive tests for the uppercase operation (API and service).
  • Updated replace-operation tests to assert standardized affected-row responses.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title clearly and concisely describes the primary enhancement—adding uppercase conversion functionality within the column operations domain—so it accurately summarizes the main feature introduced by this pull request.
Description Check	✅ Passed	The description details the addition of the uppercase conversion feature and the associated frontend, backend, and test updates, all of which correspond directly to the changes made in this pull request.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch column-operations-uppercase-conversion

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

backend/src/api/project/index.ts (1)

670-682: Consider extracting the column-existence guard.

The same information_schema check and error response now live in the replace, trim, and uppercase handlers. Pulling that guard into a shared helper (e.g., ensureColumnExists) would shrink the handlers and keep the logic in one spot if we have to tweak the validation again.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 70d20f2 and 1b16777.

📒 Files selected for processing (9)

• backend/src/api/project/index.ts (4 hunks)
• backend/src/api/project/schemas.ts (1 hunks)
• backend/src/services/uppercase-conversion.service.ts (1 hunks)
• backend/tests/api/project/project.replace.test.ts (3 hunks)
• backend/tests/api/project/uppercase.test.ts (1 hunks)
• backend/tests/services/uppercase-conversion.service.test.ts (1 hunks)
• backend/tests/upload/file-processor.test.ts (0 hunks)
• frontend/components.d.ts (0 hunks)
• frontend/src/features/data-processing/components/ColumnHeaderMenu.vue (2 hunks)

💤 Files with no reviewable changes (2)

• backend/tests/upload/file-processor.test.ts
• frontend/components.d.ts

🧰 Additional context used

🧬 Code graph analysis (4)

backend/src/services/uppercase-conversion.service.ts (1)

backend/src/services/column-operation.service.ts (1)

• ColumnOperationParams (3-6)

backend/tests/services/uppercase-conversion.service.test.ts (2)

backend/src/services/uppercase-conversion.service.ts (1)

• UppercaseConversionService (4-43)

backend/src/plugins/database.ts (3)

• initializeDb (8-48)
• getDb (50-55)
• closeDb (57-63)

backend/src/api/project/index.ts (4)

backend/src/api/project/schemas.ts (2)

• AffectedRowsSchema (61-63)
• ColumnNameSchema (54-59)

backend/src/types/error-handler.ts (1)

• ApiErrorHandler (6-211)

backend/src/services/uppercase-conversion.service.ts (1)

• UppercaseConversionService (4-43)

backend/src/types/error-schemas.ts (2)

• ApiErrors (20-26)
• ApiErrors (27-27)

backend/tests/api/project/uppercase.test.ts (1)

backend/src/plugins/database.ts (2)

• initializeDb (8-48)
• closeDb (57-63)

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Await the promise before asserting .resolves

These .resolves assertions are never awaited (nor returned), so the test finishes before the expectation runs. That turns failures into silent passes and can even race with the subsequent verification queries. Add await (or return the promise) for each .resolves usage in this file.

-      expect(service.performOperation({
-        table: 'test',
-        column: 'name',
-      })).resolves.toBe(4)
+      await expect(service.performOperation({
+        table: 'test',
+        column: 'name',
+      })).resolves.toBe(4)

Repeat the same fix for the other .resolves assertions below (empty strings, all-uppercase, special characters, unicode, etc.) so every async expectation is awaited.

Also applies to: 79-83, 174-177, 202-205, 242-245

🤖 Prompt for AI Agents

In backend/tests/services/uppercase-conversion.service.test.ts around lines
42-46 (and also apply the same change at 79-83, 174-177, 202-205, 242-245), the
test uses expect(...).resolves without awaiting or returning the promise which
allows the test to finish before the assertion runs; update each
expect(...).resolves to be awaited (e.g. await expect(...).resolves.toBe(...) or
return the promise) so the assertions run before the test completes and prevent
silent passes or race conditions with subsequent verification queries.