AppModelConfig has so many nullable fields

[asukaminato0721]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

master

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

#30919

✔️ Expected Behavior

not so many nullable fields

❌ Actual Behavior

    id: Mapped[str] = mapped_column(StringUUID, default=lambda: str(uuid4()), init=False)
    app_id: Mapped[str] = mapped_column(StringUUID, nullable=False)
    provider: Mapped[str | None] = mapped_column(String(255), nullable=True, default=None)
    model_id: Mapped[str | None] = mapped_column(String(255), nullable=True, default=None)
    configs: Mapped[Any | None] = mapped_column(sa.JSON, nullable=True, default=None)
    created_by: Mapped[str | None] = mapped_column(StringUUID, nullable=True, default=None)
    created_at: Mapped[datetime] = mapped_column(
        sa.DateTime, nullable=False, server_default=func.current_timestamp(), init=False
    )
    updated_by: Mapped[str | None] = mapped_column(StringUUID, nullable=True, default=None)


    opening_statement: Mapped[str | None] = mapped_column(LongText, default=None)
    suggested_questions: Mapped[str | None] = mapped_column(LongText, default=None)
    suggested_questions_after_answer: Mapped[str | None] = mapped_column(LongText, default=None)
    speech_to_text: Mapped[str | None] = mapped_column(LongText, default=None)
    text_to_speech: Mapped[str | None] = mapped_column(LongText, default=None)
    more_like_this: Mapped[str | None] = mapped_column(LongText, default=None)
    model: Mapped[str | None] = mapped_column(LongText, default=None)
    user_input_form: Mapped[str | None] = mapped_column(LongText, default=None)
    dataset_query_variable: Mapped[str | None] = mapped_column(String(255), default=None)
    pre_prompt: Mapped[str | None] = mapped_column(LongText, default=None)
    agent_mode: Mapped[str | None] = mapped_column(LongText, default=None)
    sensitive_word_avoidance: Mapped[str | None] = mapped_column(LongText, default=None)
    retriever_resource: Mapped[str | None] = mapped_column(LongText, default=None)
    prompt_type: Mapped[str] = mapped_column(
        String(255), nullable=False, server_default=sa.text("'simple'"), default="simple"
    )
    chat_prompt_config: Mapped[str | None] = mapped_column(LongText, default=None)
    completion_prompt_config: Mapped[str | None] = mapped_column(LongText, default=None)
    dataset_configs: Mapped[str | None] = mapped_column(LongText, default=None)
    external_data_tools: Mapped[str | None] = mapped_column(LongText, default=None)
    file_upload: Mapped[str | None] = mapped_column(LongText, default=None)

I think this need to be splited.

[dosubot]

You're right—AppModelConfig currently acts as a catch-all for many optional features, which leads to a lot of nullable fields and makes the model harder to maintain and extend. This is a known issue and is being discussed as a candidate for refactoring to improve clarity and maintainability source.

A practical way to split AppModelConfig is to group related features into separate models or tables. For example: prompt configurations, speech features, agent/tool settings, dataset/retriever configs, and external tools can each become their own related models. This approach matches how Dify already structures its Pydantic config entities, where each feature or responsibility is encapsulated in its own class and then aggregated in a higher-level config object source.

If you decide to prototype this, consider how the App class references AppModelConfig and plan for migration and backward compatibility. Refactoring in this way will reduce nullable columns, clarify responsibilities, and make future changes easier to manage.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[asukaminato0721]

also cc @laipz8200 for some opinions.