refactor!: DOCXToDocument converter - store DOCX metadata as a dict

[anakin87]

Related Issues

• fixes Cannot Upload docx document to Milvus Database because of DOCXMetadata #8727

In Documents produced by DOCXToDocument converter, DOCX metadata is stored in the docx key of meta as a DOCXMetadata dataclass.

While this approach is somewhat uncommon, it generally works because Documents are converted into dictionaries before being written to our Document Stores. The to_dict method handles this conversion, transforming also DOCXMetadata into a dictionary. When retrieving the Document from the Document Store, it won't have a DOCXMetadata dataclass but a dict, which is a bit inconsistent but not much problematic.

As you can see in the mentioned issue, Milvus Document Store (developed by the Milvus team) fails because it does not use to_dict and does not recognize the DOCXMetadata dataclass.

To improve transparency and avoid similar issues in the future (see also #8251), storing DOCX metadata directly as a dictionary makes more sense to me while keeping DOCXMetadata as an internal dataclass.

Proposed Changes:

• store DOCX metadata as a dictionary
• keep DOCXMetadata as a dataclass for internal use

How did you test it?

• CI
• Verified that with this change Milvus correctly handles Documents created by DOCXToDocument.
• I also compared the impact of storing this metadata as a dataclass vs a dict across our Document Stores in two draft PRs in core-integrations (try docx metadata with document stores - dataclass haystack-core-integrations#1350; try docx metadata with document stores - dictionary haystack-core-integrations#1334). Based on test results, there are no significant changes (keep into consideration that some Document Stores do not store nested metadata).

Notes for the reviewer

@sjrl I’d appreciate your review on this PR.

• Does my approach make sense?
• Do you see any potential negative impact on some of our users?
• (Technically, this could be considered a breaking change, but it could also be seen as a bugfix or a consistency improvement. Given the small impact, I don’t think it is worth following the breaking change policy)

Checklist

• I have read the contributors guidelines and the code of conduct
• I have updated the related issue with new insights and changes
• I added unit tests and updated the docstrings
• I've used one of the conventional commit types for my PR title: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test: and added ! in case the PR includes breaking changes.
• I documented my code
• I ran pre-commit hooks and fixed any issue

[coveralls]

Pull Request Test Coverage Report for Build 13134055176

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 91.291%

---

Totals
Change from base Build 13132521145:	0.0%
Covered Lines:	8931
Relevant Lines:	9783

---

💛 - Coveralls

[sjrl]

This looks good to me! And yes I think this is small enough to not warrant following the breaking change policy. And as you say it feels more like a bug fix since it makes this component more consistent with our other converters.