Skip to content
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

Add tests for child relations support #6

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

flvrone
Copy link
Collaborator

@flvrone flvrone commented Nov 14, 2019

Adds test for #5.

@janko, that bug is not yet fixed, but I believe this might help you figure it out.
And it also fixes a bug with Attacher#atomic_persist and nested models.

Fix Attacher#atomic_persist for embeded models.
TODO: Fix nested atributes with cascade_callbacks support.
@flvrone flvrone requested a review from janko November 14, 2019 18:04
@janko
Copy link
Member

janko commented Nov 15, 2019

Thank you, this will definitely help in figuring out a solution for #5.

Do you know why model reloading doesn't work with embedded documents? I thought it worked when I looked into the Mongoid source code, I recall seeing code that specifically handles embedded documents 🤔

@flvrone
Copy link
Collaborator Author

flvrone commented Nov 15, 2019

@janko I didn't check their code yet, but that reloading was raising an error on embedded records. The error was not obvious at all and didn't look for it in their code either.

However, that error could be "silenced" (with wrong behavior anyway) by telling Mongoid in which collection to look for the record, but that's nonsense, as there are no separate collections ("tables") for embedded records.

Anyway, for me, it feels strange to reload an embedded record, because what it requires, in fact, is to reload the "root" parent, with all the other embedded records in it, and it's not even guaranteed that after reloading our initial embedded record is still there.

So I guess embedded records are simply not meant to be reloaded on their own. I don't know if it's true though 🙂

@flvrone
Copy link
Collaborator Author

flvrone commented Oct 6, 2020

Hey @janko, I'm getting back to this one 🙂

I have a question though: can we avoid reloading at all? I'm afraid it might lead to tricky hidden bugs.

I guess it's better to deliver less functionality out of the box for Mongoid, leave it for users to take care of some things, and make it clear.

@janko
Copy link
Member

janko commented Oct 6, 2020

@FunkyloverOne Sure thing, we can just return the same model instance without reloading. I think that's reasonable in this case.

- Do not perform extra `persist` in after_save callback,
  so there's no more bugs with saving records with embedded
  models with shrine attachments.
  Call `finalize` in before_save callback now.
- Support deeply nested records.
- Skip reload for non-persisted records.
- Add more tests.
@flvrone
Copy link
Collaborator Author

flvrone commented Oct 7, 2020

@janko check it out, it fixes everything now, including #5.

@janko
Copy link
Member

janko commented Oct 7, 2020

@FunkyloverOne Thank you, I really appreciate your work on this!

Will calling Attacher#finalize in the before_save callback work with Shrine's backgrounding plugin? What happens when the background job tries to pick up the Mongo document that's not yet persisted?

@flvrone
Copy link
Collaborator Author

flvrone commented Oct 7, 2020

I believe the background job won't be able to pick it up at all, how could it?

And even if it causes any issues with backgrounding (which we do not know yet) - it's better to have no support for it and leave it to users, but have a properly working "base".

BTW I plan to test backgrounding in a project I work on tomorrow. So I will let you know what do we have there.


I see what you mean here.
Basically the best thing to do here is for the user to make sure he's dealing with persisted upfront records if he needs backgrounding.

@flvrone
Copy link
Collaborator Author

flvrone commented Oct 7, 2020

@janko how about - we give users a standalone #<name>_finalize method - so they could manually call it right after save, instead of having it in a callback?
Make it configurable? So when you need backgrounding - you need manual finalization, otherwise - just leave it in the callback.

@janko
Copy link
Member

janko commented Oct 7, 2020

@FunkyloverOne Just to check, is it not possible for Attacher#finalize to be called in after_create?

@flvrone
Copy link
Collaborator Author

flvrone commented Oct 7, 2020

It depends on what it does. if it changes the record - then we need to save it once again - and that was exactly the problem with embedded records with non-persisted parents.

@flvrone
Copy link
Collaborator Author

flvrone commented Oct 8, 2020

@janko we could also give an option to have Attacher#finalize called in after_create.

@janko
Copy link
Member

janko commented Oct 8, 2020

Yeah, that's an option, too.

Ok, I think it's time for me to step away and just let you do any changes you think are right 😉 I already gave you RubyGems access to the gem, so you're free to publish releases with the new changes.

I'm very grateful for the work you're putting into improving shrine-mongoid 🙏

TODO: add tests, especially for backgrounding.
@flvrone
Copy link
Collaborator Author

flvrone commented Oct 9, 2020

Alright, got it!
Meanwhile - I've made finalization configurable. Soon I will add more tests for it and also some notes to README.

Hmmm, I've also made this auto-finalization completely disabled by default. That's a breaking change anyway though.
The reason I think it should be completely disabled by default is to attract users attention to this important detail here, and configure it as they need explicitly. Right, I want it to be explicit, so it's easier to figure out their resulting behavior.

And then I believe I should release v2.0.0 (due to that breaking change).

@janko
Copy link
Member

janko commented Oct 13, 2020

Sounds good to me, thank you 🤘

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants