[Enhancement]: Refactor `pymilvus/orm` directory

[jac0626]

Is there an existing issue for this?

• I have searched the existing issues

What would you like to be added?

Problem

The pymilvus/orm directory has several architectural issues:

1. Misleading naming - "ORM" (Object-Relational Mapping) is a relational database concept that doesn't apply to vector databases, causing confusion for users

2. Redundant functionality - Most features in orm/ are now covered by MilvusClient:

   • Collection/Partition/Index operations → Available in MilvusClient
   • User/Role management → Available in MilvusClient
   • Database operations → Available in MilvusClient
   • Bulk Import → Available in separate bulk_writer module

3. Duplicate code - Several classes are defined in both orm/ and client/:

   • CollectionSchema / FieldSchema
   • MutationResult
   • Prepare

4. Confusing dependency structure - milvus_client/ depends on orm/, which depends on client/, creating an unclear layering

Proposed Solution

1. Merge valuable classes from orm/ (e.g., CollectionSchema, FieldSchema, connections) into the client/ directory
2. Remove redundant code (mutation.py, types.py, prepare.py)
3. Eventually remove the orm/ directory, or at minimum rename it to something more accurate

Backward Compatibility

• Keep top-level pymilvus exports unchanged - user code like from pymilvus import Collection, connections will continue to work
• Add deprecation warnings for direct imports like from pymilvus.orm import xxx with a migration period

Why is this needed?

No response

Anything else?

No response