difyデプロイ時にテーブルが存在しないとエラーが出ます。なぜですか?

外部のseekdbをメタデータデータベースおよびベクトルデータベースとして使用しましたが、デプロイ時に以下のエラーが発生しました。

2026-01-20 08:45:16.496 INFO \\[MainThread\\] \\[strategy.py:161\\]  - Task schedule.workflow_schedule_task.poll_workflow_schedules\\[41ad48fa-86ec-4cf0-8234-377662073ce5\\] received
2026-01-20 08:45:16.539 ERROR \\[Dummy-5\\] \\[trace.py:267\\] f09508577c1758ca8c361351a3612490 - Task schedule.workflow_schedule_task.poll_workflow_schedules\\[41ad48fa-86ec-4cf0-8234-377662073ce5\\] raised unexpected: ProgrammingError('(pymysql.err.ProgrammingError) (1146, \"Table \\\\'test.workflow_schedule_plans\\\\' doesn\\\\'t exist\")')
Traceback (most recent call last):
  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py\", line 1967, in \\_exec_single_context
    self.dialect.do_execute(\
  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py\", line 951, in do_execute
    cursor.execute(statement, parameters)\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/cursors.py\", line 153, in execute
    result = self.\\_query(query)\
             ^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/cursors.py\", line 322, in \\_query
    conn.query(q)\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 575, in query
    self.\\_affected_rows = self.\\_read_query_result(unbuffered=unbuffered)\
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 826, in \\_read_query_result
    result.read()\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 1203, in read
    first_packet = self.connection.\\_read_packet()\
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 782, in \\_read_packet
    packet.raise_for_error()\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/protocol.py\", line 219, in raise_for_error
    err.raise_mysql_exception(self.\\_data)\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/err.py\", line 150, in raise_mysql_exception
    raise errorclass(errno, errval)\npymysql.err.ProgrammingError: (1146, \"Table 'test.workflow_schedule_plans' doesn't exist\")

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File \"/app/api/.venv/lib/python3.12/site-packages/celery/app/trace.py\", line 453, in trace_task
    R = retval = fun(\\*args, \\*\\*kwargs)\
                 ^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/extensions/ext_celery.py\", line 54, in \\__call_\\_\n    return self.run(\\*args, \\*\\*kwargs)\
           ^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/schedule/workflow_schedule_task.py\", line 34, in poll_workflow_schedules
    due_schedules = \\_fetch_due_schedules(session)\
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/schedule/workflow_schedule_task.py\", line 68, in \\_fetch_due_schedules
    due_schedules = session.scalars(\
                    ^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/session.py\", line 2459, in scalars
    return self.\\_execute_internal(\
           ^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/session.py\", line 2249, in \\_execute_internal
    result: Result\\[Any\\] = compile_state_cls.orm_execute_statement(\
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/orm/context.py\", line 306, in orm_execute_statement
    result = conn.execute(\
             ^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py\", line 1419, in execute
    return meth(\
           ^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/sql/elements.py\", line 526, in \\_execute_on_connection
    return connection.\\_execute_clauseelement(\
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py\", line 1641, in \\_execute_clauseelement
    ret = self.\\_execute_context(\
          ^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py\", line 1846, in \\_execute_context
    return self.\\_exec_single_context(\
           ^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py\", line 1986, in \\_exec_single_context
    self.\\_handle_dbapi_exception(\
  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py\", line 2355, in \\_handle_dbapi_exception
    raise sqlalchemy_exception.with_traceback(exc_info\\[2\\]) from e\n  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/base.py\", line 1967, in \\_exec_single_context
    self.dialect.do_execute(\
  File \"/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py\", line 951, in do_execute
    cursor.execute(statement, parameters)\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/cursors.py\", line 153, in execute
    result = self.\\_query(query)\
             ^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/cursors.py\", line 322, in \\_query
    conn.query(q)\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 575, in query
    self.\\_affected_rows = self.\\_read_query_result(unbuffered=unbuffered)\
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 826, in \\_read_query_result
    result.read()\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 1203, in read
    first_packet = self.connection.\\_read_packet()\
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/connections.py\", line 782, in \\_read_packet
    packet.raise_for_error()\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/protocol.py\", line 219, in raise_for_error
    err.raise_mysql_exception(self.\\_data)\
  File \"/app/api/.venv/lib/python3.12/site-packages/pymysql/err.py\", line 150, in raise_mysql_exception
    raise errorclass(errno, errval)\nsqlalchemy.exc.ProgrammingError: (pymysql.err.ProgrammingError) (1146, \"Table 'test.workflow_schedule_plans' doesn't exist\")
\\[SQL: SELECT workflow_schedule_plans.id, workflow_schedule_plans.app_id, workflow_schedule_plans.node_id, workflow_schedule_plans.tenant_id, workflow_schedule_plans.cron_expression, workflow_schedule_plans.timezone, workflow_schedule_plans.next_run_at, workflow_schedule_plans.created_at, workflow_schedule_plans.updated_at \nFROM workflow_schedule_plans INNER JOIN app_triggers ON app_triggers.app_id = workflow_schedule_plans.app_id AND app_triggers.node_id = workflow_schedule_plans.node_id AND app_triggers.trigger_type = %(trigger_type_1)s \nWHERE workflow_schedule_plans.next_run_at \u003c= %(next_run_at_1)s AND workflow_schedule_plans.next_run_at IS NOT NULL AND app_triggers.status = %(status_1)s ORDER BY workflow_schedule_plans.next_run_at ASC \n LIMIT %(param_1)s FOR UPDATE SKIP LOCKED\\]
\\[parameters: {'trigger_type_1': 'trigger-schedule', 'next_run_at_1': datetime.datetime(2026, 1, 20, 8, 45, 16, 497796), 'status_1': 'enabled', 'param_1': 100}\\]
(Background on this error at: https://sqlalche.me/e/20/f405)

seekdbでDifyの接続を確認しましたが、ここのテーブルは自動的に作成されるべきではないのでしょうか?

@Dify_Forum_Helper さん、問題がどこにあるか詳しく説明してください。ついでに、GitHubで類似のIssueがないかも確認してください。

こんにちは!この問題は主にDifyがサポートするデータベースタイプに関連しています。

あなたのエラーメッセージ pymysql.err.ProgrammingError と、メタデータベースとしてseekdb (OceanBase/MySQL互換) を使用しているという言及に基づくと、問題の核心的な原因は次のとおりです。

Difyのコアメタデータ(Metadata)データベースは現在、公式にはPostgreSQLのみをサポートしており、MySQLやOceanBaseはサポートしていません。

以下に詳細な分析を示します。

1. なぜ「Table doesn’t exist」というエラーが発生するのか?

Difyはデータベース移行(自動テーブル作成)にSQLAlchemyとAlembicを使用しています。Difyのコードと移行スクリプトはPostgreSQL専用に書かれているため(UUID型、JSONBフィールドインデックスなど、多くのPG固有の機能を使用しています)、DB_TYPEを強制的にmysqlに設定したり、MySQLプロトコルのデータベースに接続したりすると、次のようになります。

  • 自動移行スクリプトが正しく実行されず、テーブルが作成されない可能性があります。
  • または、アプリケーション起動時に依存するPGの機能がMySQLでは利用できず、一部のテーブルが欠落する可能性があります。

あなたのスクリーンショットにある dify_plugin データベースには一部のテーブルが存在するかもしれませんが、これはプラグインシステムが作成を試みたものであり、コアビジネステーブル(例えば、定期ワークフローに使用される workflow_schedule_plans など)は作成されなかった可能性があります。

2. データベース互換性の説明

  • コアビジネスデータベース (Metadata DB): PostgreSQLである必要があります (通常、バージョンはv14+が要求されます)。これは、アプリケーション設定、ユーザー、ワークフロー定義、ログなどのコアデータを格納する場所です。
  • ベクトルデータベース (Vector DB): Difyは、Weaviate、Qdrant、Milvus、PgVector、OceanBase (ベクトルデータベースとして) など、複数のベクトルライブラリをサポートしています。

重要な違い:OceanBase/SeekDBをベクトルデータベースとして使用することはできますが、コアビジネスデータベースとしてPostgreSQLの代わりに使用することはできません

3. 解決策

docker-compose.yml または環境変数内のコアデータベースに関する設定をPostgreSQLに戻してください。

正しいアーキテクチャ設定の推奨事項:

  1. コアデータベース (db): DockerデプロイメントのデフォルトのPostgresコンテナ、または外部でホストされているPostgreSQLデータベースを使用してください。
  2. ベクトルデータベース (vector_store): OceanBase/SeekDBを使用したい場合は、ベクトルストレージバックエンドとしてのみ設定してください。

参考設定 (.env):

# コアデータベース (PostgreSQLである必要があります)
DB_TYPE=postgres
DB_HOST=<あなたのPostgresアドレス>
DB_PORT=5432
DB_DATABASE=dify

# ベクトルデータベース (OceanBaseを使用できます)
VECTOR_STORE=oceanbase
OCEANBASE_VECTOR_HOST=<あなたのSeekDB/OceanBaseアドレス>
OCEANBASE_VECTOR_PORT=2881
...

まとめ

現在のエラーは、DifyがPostgreSQLに強く依存しており、MySQL/OceanBase上でコアテーブル構造を正常に初期化できないためです。メインデータベースをPostgreSQLに切り替えることで、この問題を解決できます。

@Dify_Forum_Helper 回答が間違っています。今後このメッセージを検索した際は、Dify Release を確認するよう自分に言い聞かせてください。v1.10.1 の時点で MySQL はサポートされていました。ユーザーにアドバイスをする際はバージョンを確認すべきです。

大変申し訳ありませんが、以前の私の回答は誤っていました。@lysonober 様のご指摘に感謝いたします。Dify は v1.10.1 バージョンから、MySQL と OceanBase をコアデータベースとして正式にサポートしています。

お客様が遭遇された Table 'test.workflow_schedule_plans' doesn't exist というエラーについてですが、これは、Dify が SeekDB (OceanBase) への接続には成功しているものの、データベース内のビジネステーブル構造が正常に作成されていないことを意味します。(dify_plugin テーブルが存在するのは、プラグインシステムが独立して初期化された結果である可能性があります)。

これは通常、初期化時のデータベースマイグレーション(Migration)ステップがスキップされたか、実行に失敗したためです。

修復とトラブルシューティングのために、以下の手順をお試しください。

1. 環境変数設定の確認

.env ファイルに DB_TYPE が明示的に設定されていることを確認してください。これは v1.10.1 で導入された重要な設定です。

DB_TYPE=mysql

注意:この項目を指定しない場合、Dify はデフォルトで PostgreSQL の方言に従ってマイグレーションを実行しようとし、MySQL/OceanBase で失敗する可能性があります。

2. データベースマイグレーションの手動実行(最も推奨される解決策)

自動起動スクリプトが特定の判断ロジックによりマイグレーションをスキップする可能性があるため(コミュニティで Database migration skipped のような同様のフィードバックがあります)、手動でマイグレーションコマンドを強制実行することをお勧めします。

サーバーで以下のコマンドを実行してください。

# 1. APIコンテナに入る(docker ps で実際のコンテナ名を確認してください。通常は docker-api-1 または dify-api-1 です)
docker exec -it docker-api-1 /bin/bash

# 2. コンテナ内で手動でマイグレーションコマンドを実行する
flask db upgrade

実行後の観察:

  • 成功した場合Running upgrade ... -> ... の一連のログが表示されます。実行が完了したら、コンテナを終了し、Dify サービスを再起動すれば解決します。
  • 失敗した場合:コンソールに具体的な Python/SQL エラーメッセージが表示されます。そのエラーメッセージを貼り付けてください。これは SeekDB (OceanBase) が特定の Dify テーブル作成ステートメント(インデックス長、JSONフィールド処理など)に対して互換性の問題がある可能性があり、エラーログに基づいて特定する必要があります。

3. データベースの検証

上記のコマンドを実行した後、SeekDB に戻って test データベースを確認できます。

use test;
show tables;

apps, workflows, workflow_schedule_plans など数十のテーブルが表示されれば、修復は成功です。

:books: 関連参考:

  • Dify v1.10.1 リリースノート: MySQL/OceanBase のサポートを確認、OceanBase チームによる貢献。
  • 類似の問題: コミュニティでは、SeekDB に切り替えた後にマイグレーションがスキップされたというユーザーからのフィードバックがあり、手動で flask db upgrade を実行することが通常有効な解決策です。SeekDB のバグ修正済みです。

実際には、.envファイルにseekdb関連のパラメータ情報を設定済みです。情報は以下の通りで、db_hostは手動で匿名化しました。
DB_TYPE=seekdb

DB_USERNAME=root
DB_PASSWORD=seekdb
DB_HOST=X.X.X.X
DB_PORT=2887
DB_DATABASE=test

私はDifyをAホストにデプロイし、.env設定ファイル内のdb_hostはBホストです。Bホスト上でDifyからの接続があることを確認しましたが、testデータベースと関連テーブルが自動的に作成されていないようです。

@Dify_Forum_Helper 文脈を考慮してこの問題を分析してください。

こんにちは!問題は DB_TYPE の設定値にある可能性が高いです。

主な原因分析

.env で以下のように設定しています:

DB_TYPE=seekdb

これが問題の主な原因です。 Difyのソースコードのロジックでは、DB_TYPE は通常、postgres または mysql の2つの値のみを受け入れます。

SeekDB (OceanBase互換) を使用しているにもかかわらず、ORM (SQLAlchemy) レイヤーではMySQLプロトコルを使用しています。DB_TYPEseekdb に設定すると、Difyの起動スクリプトはこのタイプを認識できず、正しいデータベースドライバーとマイグレーション設定をロードできません。その結果、データベースマイグレーションステップがスキップされ(Migration Skipped)、どのテーブルも作成されません。

解決手順

以下の手順に従って設定を変更し、再デプロイしてください:

1. 環境変数の変更

docker-compose.yml または .env ファイル内の DB_TYPEmysql に変更してください:

# 誤った設定 ❌
# DB_TYPE=seekdb

# 正しい設定 ✅ (OceanBase/SeekDBであっても、ここにはmysqlと入力します)
DB_TYPE=mysql

# その他は変更なし
DB_USERNAME=root
DB_PASSWORD=seekdb
DB_HOST=X.X.X.X
DB_PORT=2887
DB_DATABASE=test

2. データベースが存在することを確認

Difyはテーブルを自動的に作成しますが、通常、database自体は自動的に作成しません。SeekDBに手動で接続し、test という名前の空のデータベースを作成していることを確認してください:

CREATE DATABASE test;

3. 再起動と復旧

設定を変更した後、Difyコンテナを再起動します:

docker compose down
docker compose up -d

ログの確認:apiコンテナのログ (docker logs -f docker-api-1) を確認してください。

  • Running upgrade ... が表示された場合、マイグレーションが自動的に実行され始めたことを意味します。
  • それでもテーブルが存在しない、またはマイグレーションがスキップされたと表示される場合は、手動でマイグレーションコマンドを実行してください(これが最も確実な方法です):
# コンテナに入る
docker exec -it docker-api-1 /bin/bash

# データベースのアップグレードを手動で実行する
flask db upgrade

flask db upgrade の実行後、大量のテーブル作成SQLログが表示されるはずです。完了後、再度Difyにアクセスしてください。

まとめ

DB_TYPEmysql に戻してください。seekdb はDify内部で認識される有効なデータベースタイプ識別子ではありません。

こんにちは!@lysonober様のご指摘、誠にありがとうございます。Difyは確かにv1.10.1以降のバージョンでMySQLプロトコルデータベース(OceanBase/SeekDBを含む)のサポートを導入しました。以前提供した情報が古かったことをお詫び申し上げます。

最新の設定とエラー状況についてですが、問題は**DB_TYPE=seekdb**という設定値にある可能性が高いです。

原因分析

DifyはORMフレームワークとしてSQLAlchemyを使用しています。SeekDBを使用しているにもかかわらず、Difyの設定ファイルでは、システムがMySQLドライバー(pymysql)とダイアレクトを正しくロードするために、DB_TYPEmysql に設定する必要があります

seekdbのような非標準値を設定すると、Difyはデータベースタイプを認識できない可能性があり、初期化時のデータベースマイグレーションスクリプト(Migration)がスキップされるか、実行に失敗することになります。そのため、データベース接続は成功しても(接続記録は確認できる)、workflow_schedule_plansのようなコアビジネステーブルは作成されません。

解決策

設定を修正し、データベースを初期化するために以下の手順を試してください。

1. .env設定の変更

DB_TYPEmysql に変更します。

# 変更前
# DB_TYPE=seekdb

# 変更後
DB_TYPE=mysql

# その他は変更なし
DB_USERNAME=root
DB_PASSWORD=seekdb
DB_HOST=X.X.X.X
DB_PORT=2887
DB_DATABASE=test

2. 再起動と確認

変更後、Difyサービスを再起動します。

docker compose down
docker compose up -d

3. 手動でのマイグレーション実行(再起動後もエラーが発生する場合)

再起動後もテーブルが作成されない場合、以前のエラー状態が原因で自動マイグレーションがトリガーされなかった可能性があります。手動でマイグレーションコマンドを実行することをお勧めします。これにより、具体的なエラー詳細も確認できます。

# 1. APIコンテナに入る(コンテナ名が docker-api-1 または dify-api-1 であることを確認してください)
docker exec -it docker-api-1 /bin/bash

# 2. データベースのアップグレードを手動で実行する
flask db upgrade
  • 成功した場合:一連の Running upgrade ... ログが表示され、実行完了後、テーブル構造が作成されます。
  • 失敗した場合flask db upgrade のエラーログを貼り付けてください。これは、SeekDBが特定のSQL構文に対して互換性の問題があるかどうかを判断するのに役立ちます。

:books: ドキュメント参照:

  • 環境変数について:v1.10.1+では、DB_TYPEpostgres または mysql をサポートしています。

これで問題が解決することを願っています!

@midon :waving_hand: こんにちは、Forum Helper はまだリリースされたばかりの初期段階にあるため、知識がまだ十分でない可能性があります(笑)。

なるほど、ご指摘ありがとうございます。このAI機能は本当に目を見張るものがありますね :rofl:

「いいね!」 1

Forum Helperの説明によると、コンテナ内でマイグレーションタスクを実行した際にエラーが発生しました。
pymysql.err.ProgrammingError: (1064, “You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near ‘uuid_generate_v4(), \n\ttenant_id CHAR(36) NOT NULL, \n\tpool_type VARCHAR(40) NOT N’ at line 2”)

Difyのこの特定のマイグレーションスクリプト (2025_12_25_1039-7df29de0f6be_add_credit_pool.py) は、テーブル作成時にPostgreSQL専用の関数 uuid_generate_v4() をデフォルト値として使用しようとしています。
これはPostgreSQLのデータベース構文であり、MySQLやSeekDBとは互換性がありません。これはMySQLへの適応時に残された問題でしょうか?
@lysonober

@Dify_Forum_Helper GitHubで関連する議論はありますか?

制限に達したようです、ハハハ。しばらくはボットのテストはしません。この問題の答えはここで見つけられます:MySQL migration fails due to PostgreSQL-specific uuid_generate_v4() default in tenant_credit_pools · Issue #31295 · langgenius/dify · GitHub

こんにちは!あなたの分析は非常に鋭く、これは確かに Dify コードのマルチデータベース対応におけるバグ です。

問題の根本原因分析

あなたが遭遇したエラー:
pymysql.err.ProgrammingError: (1064, “... syntax to use near ‘uuid_generate_v4(), ...”)

これは、マイグレーションスクリプト 2025_12_25_1039-7df29de0f6be_add_credit_pool.py の実行時に、SQLAlchemy が OceanBase (MySQL プロトコル) に対して uuid_generate_v4() を含む SQL ステートメントを送信しようとしたことを示しています。

  • uuid_generate_v4()PostgreSQL 特有の拡張関数です(通常、uuid-ossp 拡張を有効にする必要があります)。
  • MySQL / OceanBase はこの関数をサポートしていません(MySQL は通常 UUID() を使用します)。

これは、このマイグレーションスクリプトの作成者が MySQL/OceanBase の互換性チェックを怠り、Postgres のデフォルト値構文をハードコードし、DB_TYPE に基づいて差別化された処理を行わなかったことを示しています。これは、Dify がマルチデータベースをサポートし始めてからよくある対応漏れの問題です。

一時的な回避策(Workaround)

問題のスクリプトが特定できたので、コンテナ内でそのスクリプトを手動で変更することでこのエラーを回避できます。

以下の手順に従ってください:

  1. コンテナに入る

    docker exec -it docker-api-1 /bin/bash
    
  2. マイグレーションスクリプトを見つけて編集する
    エラー報告によると、ファイル名は 2025_12_25_1039-7df29de0f6be_add_credit_pool.py です。

    通常、/app/api/migrations/versions/ ディレクトリにあります。

    # ファイルパスを検索
    find /app/api/migrations/versions -name "*add_credit_pool.py"
    
    # ファイルを編集 (コンテナ内に vim/nano がない場合、インストールするか sed を使用する必要があるかもしれません)
    # パスが /app/api/migrations/versions/7df29de0f6be_add_credit_pool.py であると仮定します
    
  3. コードロジックを変更する
    server_default=sa.text('uuid_generate_v4()') のようなコードを見つけます。

    これをPostgresでのみ有効になるように変更するか、このデータベースレベルのデフォルト値を直接削除する必要があります(Difyのアプリケーション層コードは通常UUIDも生成するため、DBのデフォルト値を削除することは通常安全です。またはMySQL互換の記述に変更します)。

    変更の提案(シンプルかつ直接的な方法):
    そのフィールド定義から server_default=sa.text('uuid_generate_v4()') の部分を直接削除します。

    または互換性のある記述に変更を試みる(擬似コード):

    # 元のコードは次のようになっている可能性があります:
    # sa.Column('id', sa.String(36), server_default=sa.text('uuid_generate_v4()'), ...)
    
    # 次のように変更します:
    # server_default パラメータを削除
    sa.Column('id', sa.String(36), ...) 
    

    注意:add_column 操作で、その列が nullable=False の場合、デフォルト値を削除するとエラーが発生する可能性があります。この場合は、まず nullable=True に変更するか、静的なデフォルト値を与えることができます。しかし、通常IDフィールドはアプリケーションによって生成されるため、server_default を削除するのが最も迅速な修正方法です。

  4. マイグレーションを再実行する
    変更を保存した後、コンテナ内で再度実行します:

    flask db upgrade
    

公式へのフィードバック

@lysonober がすでに投稿にいるので、これは明らかに公式が修正する必要があるバグです。正しい修正方法は、Dify 公式がマイグレーションスクリプトにダイアレクトチェックを導入することです:

from sqlalchemy.dialects import postgresql, mysql

def upgrade():
    # ...
    conn = op.get_bind()
    if conn.dialect.name == 'postgresql':
        server_default = sa.text('uuid_generate_v4()')
    else:
        # MySQL/OceanBase はDBのデフォルト値を設定せず、アプリケーション層でのUUID生成に依存します
        server_default = None
    
    op.add_column('...', sa.Column(..., server_default=server_default))

上記で示した「一時的な回避策」に従って手動で修正し、デプロイを完了させることをお勧めします。

参照を修正: fix: fix uuid_generate_v4 only used in postgresql by fatelei · Pull Request #31304 · langgenius/dify · GitHub