langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #19751] fix:Inconsistent Use of collection_name Generation in get_dataset_collection_binding The table dataset_collection_bindings field is invalid #29231

New Issue
Closed
opened 2026-02-21 20:45:07 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:45:07 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/19751

State: closed
Merged: No

Fix #19724

Problem

However, this UUID is not persisted anywhere and is only used for name generation. This leads to the following issues:

   collection_name = Dataset.gen_collection_name_by_id(str(uuid.uuid4()))
  1. The generated ID cannot be reused or referenced later.
  2. It creates confusion because gen_collection_name_by_id implies that an existing ID is being used.
  3. It violates data consistency principles by discarding the ID immediately after use.

Solution
This change ensures that a unique dataset_id is generated once, then used consistently for both the entity's ID and the collection name generation. The ID is now stored in the DatasetCollectionBinding model so it can be referenced later if needed.

Changes Made

  • Generate a single dataset_id using uuid.uuid4().

  • Assign this ID to the id field of the DatasetCollectionBinding.

  • Use the same ID to generate the collection_name.

   @classmethod
    def get_dataset_collection_binding(
        cls, provider_name: str, model_name: str, collection_type: str = "dataset"
    ) -> DatasetCollectionBinding:
        dataset_collection_binding = (
            db.session.query(DatasetCollectionBinding)
            .filter(
                DatasetCollectionBinding.provider_name == provider_name,
                DatasetCollectionBinding.model_name == model_name,
                DatasetCollectionBinding.type == collection_type,
            )
            .order_by(DatasetCollectionBinding.created_at)
            .first()
        )

        if not dataset_collection_binding:
            id = str(uuid.uuid4())
            dataset_collection_binding = DatasetCollectionBinding(
                id=id,
                provider_name=provider_name,
                model_name=model_name,
                collection_name=Dataset.gen_collection_name_by_id(id),
                type=collection_type,
            )
            db.session.add(dataset_collection_binding)
            db.session.commit()

        return dataset_collection_binding

Moreover, this issue has downstream effects on the labeling feature, where the correct binding to the corresponding vector database collection is essential. Because the ID used to generate the collection name was never stored, it led to mismatches or failures when trying to associate labels with the correct vector index.

**Original Pull Request:** https://github.com/langgenius/dify/pull/19751 **State:** closed **Merged:** No --- Fix #19724 **Problem** However, this UUID is not persisted anywhere and is only used for name generation. This leads to the following issues: ```python collection_name = Dataset.gen_collection_name_by_id(str(uuid.uuid4())) ``` 1. The generated ID cannot be reused or referenced later. 2. It creates confusion because gen_collection_name_by_id implies that an existing ID is being used. 3. It violates data consistency principles by discarding the ID immediately after use. **Solution** This change ensures that a unique dataset_id is generated once, then used consistently for both the entity's ID and the collection name generation. The ID is now stored in the DatasetCollectionBinding model so it can be referenced later if needed. **Changes Made** - Generate a single dataset_id using uuid.uuid4(). - Assign this ID to the id field of the DatasetCollectionBinding. - Use the same ID to generate the collection_name. ```python @classmethod def get_dataset_collection_binding( cls, provider_name: str, model_name: str, collection_type: str = "dataset" ) -> DatasetCollectionBinding: dataset_collection_binding = ( db.session.query(DatasetCollectionBinding) .filter( DatasetCollectionBinding.provider_name == provider_name, DatasetCollectionBinding.model_name == model_name, DatasetCollectionBinding.type == collection_type, ) .order_by(DatasetCollectionBinding.created_at) .first() ) if not dataset_collection_binding: id = str(uuid.uuid4()) dataset_collection_binding = DatasetCollectionBinding( id=id, provider_name=provider_name, model_name=model_name, collection_name=Dataset.gen_collection_name_by_id(id), type=collection_type, ) db.session.add(dataset_collection_binding) db.session.commit() return dataset_collection_binding ``` Moreover, this issue has downstream effects on the labeling feature, where the correct binding to the corresponding vector database collection is essential. Because the ID used to generate the collection name was never stored, it led to mismatches or failures when trying to associate labels with the correct vector index.
yindo added the pull-request label 2026-02-21 20:45:07 -05:00
yindo closed this issue 2026-02-21 20:45:07 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#29231
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?