Skip to content

Store.save raises if document id provided in _id field #964

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mariokostelac opened this issue Sep 7, 2020 · 4 comments
Open

Store.save raises if document id provided in _id field #964

mariokostelac opened this issue Sep 7, 2020 · 4 comments
Labels

Comments

@mariokostelac
Copy link

Store.save(document) with a document serializing _id field raises because ElasticSearch does not allow _id being serialized as part of the document body.

While investigating the fix, I've found interesting differences between update and save methods

  • update uses __extract_id_from_document, which
    • treats id as _id for routing
    • removes _id and id from the document
    • does not store id outside of _id field
    • treats id as _id for routing
  • save uses __get_id_from_document, which
    • treats id as _id for routing
    • does not remove _id or id from the document
    • tries to store id if it exists
    • makes the save call fail if document serializes _id.

Having this behaviour forces users to define :id field, instead of being able to define :_id only. Is this a bug or such behaviour is introduced on purpose?

If it's on purpose, I'd like to get some guidance on using :id and :_id field with this gem.

@stale
Copy link

stale bot commented Nov 7, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 7, 2020
@stale stale bot closed this as completed Nov 15, 2020
@mariokostelac
Copy link
Author

This looks a bit aggressive closing policy to me given that there were no commits for 4 months. Is this repository still actively maintained?

@picandocodigo
Copy link
Member

@mariokostelac sorry about that, the repository is still being maintained but other work has taken priority over it. That being said I am modifying stalebot's policy to be less aggressive and try to make some time in between other work to look at the issues here and hopefully releasing an update soon. We initially added it to see if some issues from years ago were still valid, so it doesn't need to be this aggressive right now. Thank you for your patience!

@picandocodigo picandocodigo reopened this Jan 5, 2021
@stale stale bot removed the stale label Jan 5, 2021
@mariokostelac
Copy link
Author

@picandocodigo that makes perfect sense. Thanks for being transparent.

@stale stale bot added the stale label Jun 16, 2021
@elastic elastic deleted a comment from stale bot Jun 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants