Please save fetch(), fetchAll(), and fetchColumn

[NetworkDevHead]

Abandoning these critical methods is going to break thousands of lines of code for me, and millions of lines of code across the community. I absolutely cannot fathom why Doctrine 3 is abandoning these longstanding methods. The new methods add nothing, they are not more understandable and they don't appear to serve any real purpose. Widespread, important software like Doctrine needs to have very good reason to break backward compatible. This feels arbitrary and capricious and is going to break many applications and waste vast amounts of developer time. Why? Please consider this bizarre fork away from PDO and continue to support continuity in Doctrine. Thank you.

[greg0ire]

Why?

See #4007

[beberlei]

This change is rolled out over a very long time and the changes will not be made in DBAL 3 immediately where fetch and fetchAll are still available because of the criticalness of the change.

[NetworkDevHead]

I don't think the maintainers have considered the full impact of this change. Especially in the early days, Doctrine EntityManager was inadequate (only a couple methods, very cumbersome to do advanced queries) and QueryBuilder is extremely difficult to use. Also there are scenarios where data is not stored in an entity at all. PDO and its syntax are familiar to PHP developers so using DBAL fetch() and fetchAll() is a very natural solution. The "upside" of this change is not a net gain for Doctrine. The new methods are less understandable than PDO. Please reconsider.

[greg0ire]

PDO and its syntax are familiar to PHP developers so using DBAL fetch() and fetchAll() is a very natural solution.

Datapoint: I have never in my life used PDO directly. For me, it went like this:

• mysql_*
• symfony1 + "Doctrine 1" with PDO hidden under the hood
• symfony2 + "Doctrine 2"

So your claim that PDO and its syntax are familiar to PHP developers does not apply to me, and does not feel natural to me, but maybe it's just me.

The new methods are less understandable than PDO.

Let's use Hitchen's razor here. They are more understandable than PDO.

Also, your claim at symfony/symfony#40686 (comment) that the only reason people use Doctrine is Symfony is wrong, and you can see here why: https://packagist.org/packages/doctrine/dbal/dependents?order_by=downloads

Trying to get Symfony folks to pressure us into reverting the way you did does not feel very nice. I'm glad they reacted the way they did.

[NetworkDevHead]

This change basically breaks a core Symfony API, it is an appropriate forum for discussing the unjustified changes your team is bringing to DBAL. The new methods bring no benefit when compared to how much code it is going to break and how much harder it is going to be to get new developers started with Symfony and Doctrine.

[greg0ire]

I think you underestimate new developers. Somebody having to learn Symfony and Doctrine has a lot more to absorb than just how to use the API of the DBAL. Also, that's definitely not something they will learn at first. Learning how to use the DBAL is something that comes when the ORM is not enough for your use case.

Regarding the number of lines of code it breaks, I'll quote from #4007 :

As far as I can tell, most of the code can be fixed almost by find and replace.

Maybe rector could help as well?

[NetworkDevHead]

For me it was the opposite, as a new PHP dev I was slowly learning ORM and leaning on DBAL and the familiarity with PDO. I have quite a lot of code that's impacted, and yes it's not a major change in the scheme of things. I think why I'm so upset is that it breaks the implicit promise of Symfony and Doctrine around stability and well-reasoned changes that support the broader PHP community. I really don't see the gain from this change, it feels like a change for its own sake and the new code is ugly.

[greg0ire]

For me it was the opposite, as a new PHP dev I was slowly learning ORM and leaning on DBAL and the familiarity with PDO.

Nice, now you're starting to acknowledge that people are different, and your experience cannot be generalized to everyone 👍

I really don't see the gain from this change, it feels like a change for its own sake

Have you read #4007 ? Doesn't the lengthy description it comes with demonstrate that it precisely isn't a change for the sake of change?

the new code is ugly

Is it?

[beberlei]

@NetworkDevHead Symfony changes APIs and deprecates much more and more frequently than Doctrine ever could. In addition they don't keep deprecations around for multiple major versions. Just ignore the deprecations for now and most likely at some point you can use rector to auto upgrade your code to the new API wirh little effort.

Locking this issue as we seem to be going in circles.