[Doctrine] Suggest reusable bundles use explicit name configurations for Doctrine entities

[mpdude]

This may be highly opinionated and not everyone's liking, but at least I wanted to bring this potential issue to attention.

The options are:

a) Be explicit in the configuration for everything where ambiguity might be an issue
b) Do not use explicit name configurations at all, but then, at the same time, do not make any assumptions about e. g. column names, for example in Doctrine native queries.

[MalteWunsch]

With my limited overview of the bundle ecosystem, I'm not sure about the use case of plain SQL in bundles.

Two use cases cross my mind:

1. Migrations. But I wonder if they should be executed right from the bundle? Personally, I like to copy bundle migrations into my app and execute only the app's migrations for better control. And when I already copy a bundle migration into my app, it is easy to replace only the table and column names, if needed.
2. Performance. But I wonder how well that resonates with the reusability of the bundle (which is the focus of the document this PR suggests to change)? To me, reusability is strongly connected to a nice object oriented approach. Hence I have a tendeny to chose the more reusable DQL (relying on class attribute names) over the more performant SQL (relying on database column names) in a bundle, neglecting the need to hardcode column names. Performance is a problem that I typically approach in an application rather than a bundle.

On the other hand, hardcoding table and column names in bundles might force applications to either a) accept a mixture of naming strategies or b) copy the bundle's ORM configuration as a whole and only change the names to match their own naming strategy. But replacing whole configurations is not very upgrade-friendly.

So for now, I'd suggest the opposite as a best practice: "do not hardocde table and column names".

(A third option is to give reasons for both sides, but such a sophisticated approach may not fit well in a straight forward "Best Practices" document.)

As you say, highly oppinionated 😀

[javiereguiluz]

I like this, but I'm pinging @derrabus, a Doctrine expert, in case he wants to share comments or tweaks about this proposal. Thanks!

[mpdude]

I am not asking this to annoy anyone, but rather because it’s a first world problem I’ve run into on several occasions 😁

[javiereguiluz]

Let's close this as "won't fix". The only feedback we received points some problems about this proposal, so it's not something that will always/mostly produce a better result, so it probably can't be listed as a "best practice".

@mpdude this doesn't mean that you are wrong. The issue that you pointed is true ... but, as pointed in the previous comments, instead of using explicit naming maybe a better solution is to use builders and not plain SQL queries.

Thanks.