Deprecate AUTO identifier generator strategy
#8893
Comments
|
An alternative could be that we make the ID generator strategy mapping configurable. The defaults would remain as-is for eternity, but if someone started a new app, they could decide that |
|
They would have to know about all this, though, wouldn't they? The scenario I fear might happen then is:
|
Yes. In Symfony apps, we could solve this with a recipe. In general, we could deprecate not configuring this mapping, so that we can throw in 3.0 when AUTO is used without a configured strategy for the database that is used. Maybe there's a better solution, I'm just brainstorming.
I don't know if for instance sequences on Postgres are really the inferior choice, tbh. The idea is to allow the dev to make that choice. The |
|
Postgres now also has an identity / autoincrement like ID, I talked with Sergei about it a while ago, but forgot what it was exactly. It might be necessary to add this to DBAL and then we could really think about removing AUTO and making this explicit. Good DX Idea! |
|
@beberlei I think it might be the syntax mentioned in doctrine/dbal#5614 It does indeed not seem supported in the DBAL yet, so this is probably too early. Note that there is already some sort of support for autoincrement with the use of
How so? I think if we implement the above in Postgres, then switching to |
Would it be possible to introduce an API where the consumer could actually prefer the way to generate identity values if the target platform supports both? The defaults in ORM 2.x could correspond to the logic of the In ORM 3.0, the defaults could be removed. |
I don't understand that part. Since the ORM would have defaults, the strategy would know what method to pick, wouldn't it? Or are you talking about ORM 3 where there would be no defaults? |
|
The |
|
Sounds like a good plan. That way, Symfony application could be configured with a recipe to have "auto" mean "identity", and only newly-created apps would be affected. Configuration is accessible from the CMF where we need to intervene: |
|
Meanwhile, I created an issue on the DBAL to talk about identity columns: doctrine/dbal#4744 |
|
@greg0ire its a good idea! We would have a new configuration option accessible as |
|
Ok, so if somebody uses
there would be a map called
|
I think the vast majority of platforms support several strategies ( |
|
For the end-user of the ORM, whether it's an identity column or a sequence-based implementation, the result is the same: the value in the column is auto-incremented. Why should they bother about the implementation details? This is different than say UUID where the resulting generated value is psudo-random. What I'm saying is, we could probably rethink the granularity of this API and not expose |
If I believe doctrine/dbal#5614 , the user might want to use the ORM in some scenarios, and use SQL in others (to perform inserts), and then it becomes more cumbersome to use a sequence than to use SERIAL.
If we do that, how will the user control if a SEQUENCE or SERIAL or in the future, |
|
It looks like this discussion heavily overlaps with #8850 (specifically, #8850 (comment)). I agree that SERIAL should be preferred to use if it's available on a given platform since this is eventually what users want. But if the platform only supports sequences, proper implementation will make it indistinguishable from |
|
@morozov are you saying that what I have done in #8931 for |
|
I probably confused
As an ORM-level API, yes. If a user chooses
At least as an upgrade path, yes. Eventually, the ORM could just choose the default implementation for the platform. |
|
To me, |
|
Note that if |
|
In one project I'm switching from MySQL to Postgres and now getting this deprecation, but none of my entities use generated ID's so a little bit strange to get this deprecation :) |
|
I have the same deprication, but how to fix it? |
|
Hey, I just ran into the following deprecation in a new app: To fix the deprecation, I used a compiler pass to call <?php
// src/Kernel.php
declare(strict_types=1);
namespace App;
use Override;
use Doctrine\DBAL\Platforms\PostgreSQLPlatform;
use Doctrine\ORM\Mapping\ClassMetadata;
use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\HttpKernel\Kernel as BaseKernel;
class Kernel extends BaseKernel
{
use MicroKernelTrait;
#[Override]
protected function build(ContainerBuilder $container): void
{
$container->addCompilerPass(new class() implements CompilerPassInterface {
public function process(ContainerBuilder $container): void
{
$container->getDefinition('doctrine.orm.default_configuration')
->addMethodCall(
'setIdentityGenerationPreferences',
[
[
PostgreSQLPlatform::class => ClassMetadata::GENERATOR_TYPE_SEQUENCE,
],
]
);
}
});
}
} |
…ine/orm#8893] + Symfony.lock update (forgotten on a previous commit)
|
@adrienbrault thanks it helped, but actually in my case, I could avoid it by updating DBAL to version 4:
|
This strategy allows to pick the preferred strategy given the current platform. It allows full portability because you are guaranteed to have a working strategy no matter which RDBMS you use.
The issue is that a given strategy might be optimal at some point in time, then letter better strategies emerge.
For instance, for PostgreSQL,
AUTOtranslates to using sequences, but, as mentioned in doctrine/dbal#5614 , that might no longer be the best strategy.Since we cannot really release a new major version of the ORM every time this happens, I suggest we deprecate the
AUTOstrategy and let people explicitly pick one.The obvious drawback is that full portability is lost.
The text was updated successfully, but these errors were encountered: