but nothing really worked. At the moment I pass the OrderItem properties as a single array and in createAction I merge them into corresponding objects and append them to the Order object.
When I make a var_dump in createAction, the Order object contains all OrderItems. But I have seen that “parentOrder” is null. How can I solve this problem? Do I have to add something explicitly in the setter function of the Order class?
Ah, the neverending (bidirectional) *ToMany unintuitivity strikes again Yes, this is not straightforward to get right (as of now) and I had dozens of occasions where this came up and haunted people. It’s a bit tricky to do correctly due to how doctrine works.
I have tried to somehow better document how to work with *ToMany relations and am still working on changes to make the implementation side more straightforward. Here’s a few references that hopefully help you understand the underlying “problem” that you see:
A related issue that will come up, if you naively build a setter for your ToMany collection property:
and finally (coming with Flow 7) it will become a bit more “straightforward”:
Sorry, it’s quite a bit to chew through, but I’m greatly recommending sticking to it to understand the issue at hand, because it’s maybe the most critical one you will find when building a domain model.
If you’re left puzzled after reading the above, don’t hesitate to come back with questions - I’ll try my best to make things clearer then.
Well, it’s not super hard, it’s just a lot of subtlety involved that one is better to understand first
With your current implementation, it works now, but I suggest to still take a look at https://github.com/neos/flow-development-collection/pull/2185 - $this->orderItems = $orderItems might cause you some trouble later on and it’s highly recommended to never overwrite an existing doctrine Collection unless it’s intended. Only use the add/removeElement methods. Right now that means you need to “diff” the incoming collection against the existing yourself (see code example in the PR). With the other PR you could avoid that and just implement an add/remove method in your domain model and Flow will take care, but that is yet to be merged.
Making the relation unidirectional as explained in the documentation section might be a good idea for modelling reasons, but is not required to make things work. At least if you do find the bidrectionality causes troubles, you have something in the back of your head