SEZ9 commented on issue #12704: URL: https://github.com/apache/seatunnel/issues/12704#issuecomment-6378603131
@WXPNG — yes, fixing this for Elasticsearch/OpenSearch is still wanted. Current `dev` still builds the composite `_id` by joining the formatted primary-key values with `key_delimiter`, so the collision described in this issue remains possible. The earlier PR closure was a CI/workflow-detection problem, not a code objection. Reusing the opt-in `key_encoding` approach that landed for Easysearch/Typesense is the right direction. The one hard constraint is unchanged: the existing delimiter-based `_id` must stay the default, because it is the persisted upsert identity for existing indices; the collision-safe encoding must be an explicit opt-in. Nothing else is in progress for Elasticsearch/OpenSearch, so a contribution from you is welcome. Please either revive the closed PR rebased on current `dev` or open one focused replacement PR, including: - tests for the colliding tuples, the exact legacy default IDs, a single-key control, and null values; - coverage of the shared Elasticsearch/OpenSearch serialization path; - an integration assertion that the two formerly colliding rows end up as distinct documents; - EN/ZH connector docs describing the new option, the compatibility default, and migration behavior. Ping me on the PR when it is up and I will review. <!-- streview-comment:1985 --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
