DDC-399: Doctrine\DBAL\DBALException: Type XXX already exists. #495

Closed
opened 2026-01-22 12:40:24 +01:00 by admin · 5 comments
Owner

Originally created by @doctrinebot on GitHub (Mar 9, 2010).

Jira issue originally created by user jakajancar:

Creating Doctrine\ORM\Configuration twice and using setCustomTypes each time will cause the aforementioned exception, because Doctrine\DBAL\Types\Type::addType() adds to a static array.

Originally created by @doctrinebot on GitHub (Mar 9, 2010). Jira issue originally created by user jakajancar: Creating Doctrine\ORM\Configuration twice and using setCustomTypes each time will cause the aforementioned exception, because Doctrine\DBAL\Types\Type::addType() adds to a static array.
admin added the Bug label 2026-01-22 12:40:24 +01:00
admin closed this issue 2026-01-22 12:40:25 +01:00
Author
Owner

@doctrinebot commented on GitHub (Mar 10, 2010):

Comment created by romanb:

I agree that there is currently a problem. There are a few options:

  1. Make setCustomTypes() et al static on the Configuration, so that its clear they are "global" to all instances.

  2. Move the type map into the Configuration, thereby making it configuration-local, but leave the instance control (flyweight) in the Type class. This would require changing all the code that uses Type::getType to go through the configuration and it means another level of indirection ($config->getType() -> Type::getType)

  3. Same as 2 but also move the instance control (flyweight) into the Configuration. As a result the Type constructor must be made public thereby giving up full control over the instances. This would only change the static Type::getType lookup into $config->getType, so no additional level of indirection.

2 + 3 require a bit of refactoring, especially in places where Type::getType is used without the Configuration being within reach.
1 would be easy but would still leave this configuration global and shared.

Opinions?

@doctrinebot commented on GitHub (Mar 10, 2010): Comment created by romanb: I agree that there is currently a problem. There are a few options: 1) Make setCustomTypes() et al static on the Configuration, so that its clear they are "global" to all instances. 2) Move the type map into the Configuration, thereby making it configuration-local, but leave the instance control (flyweight) in the Type class. This would require changing all the code that uses Type::getType to go through the configuration and it means another level of indirection ($config->getType() -> Type::getType) 3) Same as 2 but also move the instance control (flyweight) into the Configuration. As a result the Type constructor must be made public thereby giving up full control over the instances. This would only change the static Type::getType lookup into $config->getType, so no additional level of indirection. 2 + 3 require a bit of refactoring, especially in places where Type::getType is used without the Configuration being within reach. 1 would be easy but would still leave this configuration global and shared. Opinions?
Author
Owner

@doctrinebot commented on GitHub (Mar 10, 2010):

Comment created by jakajancar:

I can't comment on the solutions, I'm not even sure what "instance control" is.

I would just expect Configuration to be something I feed to the ORM (analogous to a foo.conf file) and I would expect it to not be modified by the ORM (like I wouldn't expect it to overwrite my config file).

@doctrinebot commented on GitHub (Mar 10, 2010): Comment created by jakajancar: I can't comment on the solutions, I'm not even sure what "instance control" is. I would just expect Configuration to be something I feed to the ORM (analogous to a foo.conf file) and I would expect it to not be modified by the ORM (like I wouldn't expect it to overwrite my config file).
Author
Owner

@doctrinebot commented on GitHub (Mar 15, 2010):

Comment created by romanb:

This has been fixed for now by removing these irritating instance methods. Type configuration remains global for now. Use Type::addType() and Type::overrideType(). This makes it clear that this is not configuration-local. We may consider making the type configuration local to a Configuration instance in a future release.

@doctrinebot commented on GitHub (Mar 15, 2010): Comment created by romanb: This has been fixed for now by removing these irritating instance methods. Type configuration remains global for now. Use Type::addType() and Type::overrideType(). This makes it clear that this is not configuration-local. We may consider making the type configuration local to a Configuration instance in a future release.
Author
Owner

@doctrinebot commented on GitHub (Mar 15, 2010):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Mar 15, 2010): Issue was closed with resolution "Fixed"
Author
Owner

@doctrinebot commented on GitHub (Mar 15, 2010):

Comment created by jakajancar:

Sounds good.

Please also update the documentation:
http://www.doctrine-project.org/documentation/manual/2_0/en/basic-mapping#custom-mapping-types

@doctrinebot commented on GitHub (Mar 15, 2010): Comment created by jakajancar: Sounds good. Please also update the documentation: http://www.doctrine-project.org/documentation/manual/2_0/en/basic-mapping#custom-mapping-types
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#495