feat: add Database Operation tool

[XiaoLey]

Description

Introduced a new Database Operation tool that allows execution of SQL SELECT statements and returns corresponding results. This enhancement improves the convenience of database operations. Considering the rigorousness of database operations, currently only SELECT statements are supported. Support for other types of SQL statements will be added in future updates.

Currently supported ORDBMS include PostgreSQL and MySQL.

simplescreenrecorder-2024-06-23_04.00.14.mp4

Fixes #5526 (issue)

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update, included: Dify Document
• Improvement, including but not limited to code refactoring, performance optimization, and UI/UX improvement
• Dependency upgrade

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• TODO

Suggested Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods
• optional I have made corresponding changes to the documentation
• optional I have added tests that prove my fix is effective or that my feature works
• optional New and existing unit tests pass locally with my changes

[lukefan]

Your idea to add user-defined tables to Dify's PostgreSQL database is interesting and could enhance its functionality. For a simpler initial implementation, we could consider the following:

Basic table structure: Allow users to create simple tables with basic data types (e.g., text, number, date).
CRUD operations: Provide APIs for users to perform basic Create, Read, Update, and Delete operations on their custom tables.
Simple querying: Enable basic querying capabilities, such as filtering and sorting.
User-level isolation: Ensure each user can only access their own custom tables.
Straightforward API: Design a simple, intuitive API for table creation and data manipulation.
Basic data export: Allow users to export their table data in common formats like CSV.
This simplified approach avoids complex data structures, performance optimizations, and multi-table relationships initially. It provides a foundation that can be expanded upon in the future if needed.

What are your thoughts on this simplified approach? Do you have any specific use cases in mind for these custom tables?

[XiaoLey]

Your idea to add user-defined tables to Dify's PostgreSQL database is interesting and could enhance its functionality. For a simpler initial implementation, we could consider the following:

Basic table structure: Allow users to create simple tables with basic data types (e.g., text, number, date). CRUD operations: Provide APIs for users to perform basic Create, Read, Update, and Delete operations on their custom tables. Simple querying: Enable basic querying capabilities, such as filtering and sorting. User-level isolation: Ensure each user can only access their own custom tables. Straightforward API: Design a simple, intuitive API for table creation and data manipulation. Basic data export: Allow users to export their table data in common formats like CSV. This simplified approach avoids complex data structures, performance optimizations, and multi-table relationships initially. It provides a foundation that can be expanded upon in the future if needed.

What are your thoughts on this simplified approach? Do you have any specific use cases in mind for these custom tables?

Your suggestion is excellent and aligns with what I hope to achieve. However, Dify currently supports only a limited set of data types (string, number, boolean, and select). To implement more advanced features, I believe the "array" type is essential. While it's possible to simulate an array using the string type, it's neither intuitive nor easy to maintain.

At present, I feel that directly using SQL statements is just a temporary solution and can be quite risky. If we can support more diverse data types in the future, we might even be able to avoid SQL statements altogether.

Thank you for your understanding and support. Looking forward to further discussions on this topic.