There's no reason for longer supporting both Mysqli and PDO.
Supporting only PDO allows us also to use named parameters in the core.
Are named Parameters such a huge gain, compared to unnamed ones? As PDO is a emulation layer, it has its drawbacks especially when emulation layer for prepared statements is active (which is the default).
If I had a vote, I'd vote against it.
@bbak Thank you very much for sharing your opinion! In some situations, especially when dynamically building conditions it is definitely a huge gain.
But the emulation layer is a good point, ... :)
reverted, see: https://github.com/pimcore/pimcore/commit/bfebc3685e2a611fd545182134b9d30c29d84447
Pimcore continues to support both adapters for now.
Pimcore 5 is going to use Doctrine DBAL anyway, which supports named parameters for both PDO and Mysqli.
+1 for doctrine! :)
A bit offtopic ... but, if you're moving to Doctrine anyway, I propose you have a look at a NestedSet Implementation for Doctrine. While NestedSet (also called preorder tree traversal) may be slow in inserting a node in a (huge ! ) tree, it's lightning fast in reading it - basically it's possible to generate the whole tree-structure with one SQL Query - no recursion like in the adjacency List approach or "LIKE" Queries as in materialized path.
We managed trees (using "native" SQL) with several 10k Nodes without any notable slowdown in read speed and inserting nodes was also ok, since there are just some integers to update.
Most helpful comment
reverted, see: https://github.com/pimcore/pimcore/commit/bfebc3685e2a611fd545182134b9d30c29d84447
Pimcore continues to support both adapters for now.
Pimcore 5 is going to use Doctrine DBAL anyway, which supports named parameters for both PDO and Mysqli.