Add tests for child relations support

[flvrone]

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.

[janko]

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]

@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]

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]

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

[flvrone]

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

[janko]

@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]

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]

@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]

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

[flvrone]

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]

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

[janko]

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 🙏

[flvrone]

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]

Sounds good to me, thank you 🤘