Details
-
Type:
Documentation
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.0
-
Fix Version/s: None
-
Component/s: Documentation
-
Security Level: All
-
Labels:None
Description
If you need to override the ID Generator, e.g. during a migration, you can do that in your migration script as follows:
Overriding the ID generator
$em->getClassMetadata('foo\bar\Entity')->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator());
$em->getClassMetadata('foo\bar\Entity')->setIdGeneratorType(constant('Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE'));
Make sure that both calls equal to the same generator type. You can now modify the @Id fields in your entities. Additionally, make sure that you set the IdGenerator after you created the database using e.g. SchemaTool->create().
Activity
Timo A. Hummel
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Description |
If you need to override the ID Generator, e.g. during a migration, you can do that in your migration script as follows: {panel:title=Overriding the ID generator} $em->getClassMetadata('foo\bar\Entity')->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator()); $em->getClassMetadata('foo\bar\Entity')->setIdGeneratorType(constant('Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE')); {panel} Make sure that both calls equal to the same generator type. |
If you need to override the ID Generator, e.g. during a migration, you can do that in your migration script as follows: {panel:title=Overriding the ID generator} $em->getClassMetadata('foo\bar\Entity')->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator()); $em->getClassMetadata('foo\bar\Entity')->setIdGeneratorType(constant('Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE')); {panel} Make sure that both calls equal to the same generator type. You can now modify the @Id fields in your entities. Additionally, make sure that you set the IdGenerator *after* you created the database using e.g. SchemaTool->create(). |
Timo A. Hummel
made changes -
| Summary | Cockbook: Overriding the ID Generator during a database migration | Cookbook: Overriding the ID Generator during a database migration |
Benjamin Eberlei
made changes -
| Workflow | jira [ 12311 ] | jira-feedback [ 13901 ] |
Benjamin Eberlei
made changes -
| Workflow | jira-feedback [ 13901 ] | jira-feedback2 [ 15765 ] |
Benjamin Eberlei
made changes -
| Workflow | jira-feedback2 [ 15765 ] | jira-feedback3 [ 18022 ] |
This list may be incomplete, as errors occurred whilst retrieving source from linked applications:
- Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-993, expand=changesets[-21:-1].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)
Hi, this doesn't seem to work for me. I have written a small database export / import utility. As long as I use the automatic ID generation, everything works flawlessly, but I'm trying to preserve the existing IDs. I do exactly what you've suggested in your post. It works for @OneToOne relations, but I get the following error messages when persisting entities that are parts of @ManyToOne relations:
Notice: Undefined index: [....] in [...]Doctrine/ORM/UnitOfWork.php on line 2655
I'm using version 2.2.2
Am I doing something wrong?