refactor: Use Repository Pattern for Model Layer

[hieheihei]

close #27662

Important

1. Make sure you have read our contribution guidelines
2. Ensure there is an associated issue and you have been assigned to it
3. Use the correct syntax to link this PR: Fixes #<issue number>.

Summary

Screenshots

Before	After
...	...

Checklist

• This change requires a documentation update, included: Dify Document
• I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.
• I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods

[gemini-code-assist]

Summary of Changes

Hello @hieheihei, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces the Repository pattern for retrieving WorkflowRun objects within the Message and WorkflowAppLog models. This change aims to decouple the models from direct database access, enhancing modularity, testability, and maintainability by centralizing data access logic through a dedicated repository.

Highlights

• Refactor to Repository Pattern: The pull request refactors the workflow_run properties in both Message and WorkflowAppLog models to utilize the Repository pattern, abstracting direct database access.
• Centralized WorkflowRun Retrieval: Instead of direct db.session queries, WorkflowRun instances are now fetched via DifyAPIRepositoryFactory.create_api_workflow_run_repository and its get_workflow_run_by_id_without_tenant method.
• Dependency Injection for Session: A sessionmaker is now explicitly created and passed to the repository factory, ensuring proper session management for the new repository-based approach.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors Message.workflow_run and WorkflowAppLog.workflow_run to use the Repository pattern, which is a good step towards decoupling models from direct database access.

However, the current implementation introduces a performance issue by creating a new sessionmaker on every property access. This is inefficient and should be addressed by creating the sessionmaker and repository instances once and reusing them, for example at the module level.

Additionally, there's a potential bug in WorkflowAppLog.workflow_run where it doesn't check for a None workflow_run_id before making a repository call, which could lead to errors.

I've added specific comments with suggestions to address these points.