Disallow orphan removal attribute on many-to-one

[greg0ire]

It only makes sense for collections, and there is no collection here.
Plus the docs do not say it is supported.
See
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-associations.html#orphan-removal

[Ocramius]

@greg0ire please write a test verifying that it DOESN'T work

[greg0ire]

@Ocramius just to be sure, you want me to create an XML mapping with that attribute and test that it doesn't validate against the XSD?

[greg0ire]

It might be my lazyness speaking, but I don't see the point of this test:

1. if someone wants to add that back, you are probably going to ask them to provide a test ensuring it works, which would make a lot more sense, and they will remove mine. A safeguard against someone sneakily adding it seems overkill.
2. on a semi-trolling note, if I add a test for orphan-removal, why not add it for all the other possible combinations of english words?

[greg0ire]

If you mean I should test that the expected behavior does not work, the expected behavior is not defined.

[Ocramius]

@greg0ire no, I'd want a test that verifies that the orphan removal doesn't kick in :-)

[greg0ire]

So:

1. create an invalid mapping with that, which makes Validate XML mapping against XSD file #6728 harder :/
2. set the reference to the "one" side to null
3. persist
4. clear
5. assert findOne still returns something

[gerryvdm]

How should one write a test for this? With a many-to-one there is no collection to manipulate and subsequently trigger this behavior.

[ciaranmcnulty]

The set of 'things that don't happen' is quite large, surely?

[Ocramius]

Yes it is, but that's also because the "set of things we don't know to be happening" is almost equally big. On 13 Oct 2017 17:41, "Ciaran McNulty" <[email protected]> wrote: The set of 'things that don't happen' is quite large, surely? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6772 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakF43Aw4motTFP4UAAIqrOyWkn2Zkks5sr4SWgaJpZM4P4lr9> .

[greg0ire]

Working on it.

[greg0ire]

And it only passes with sqlite but not database that ensure integrity. What do I do now @Ocramius ? setup a null cascade? Or do I remove this commit now that we have proof?

[greg0ire]

I went ahead and setup a set null cascade, now the test pass with mysql, but not pg:

SELECT UUID_GENERATE_V4()

               ^

HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

How do I do this: https://stackoverflow.com/questions/12505158/generating-a-uuid-in-postgres-for-insert-statement#12505220 ?

EDIT: let's just not do it and set uuids manually

[greg0ire]

I moved the proof to #6774 so that you can decide whether to merge both or just this one more easily, and in the order you see fit.