DDC-2747: Doctrine Checking Null but not default #3435

Closed
opened 2026-01-22 14:19:52 +01:00 by admin · 4 comments
Owner

Originally created by @doctrinebot on GitHub (Oct 17, 2013).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user spuy767:

Doctrine ORM checks fields for the acceptance of null values on entity commits. It does not, however, check if those same fields allow have default values. Our DBA likes to specify not-null, in addition to a default, so that a manual entry of a null value cannot take place. It seems that Doctrine should check that the field has a default value after it checks if it accepts null, in order to prevent errors on not-null fields with default values that are not passed explicit values.

Originally created by @doctrinebot on GitHub (Oct 17, 2013). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user spuy767: Doctrine ORM checks fields for the acceptance of null values on entity commits. It does not, however, check if those same fields allow have default values. Our DBA likes to specify not-null, in addition to a default, so that a manual entry of a null value cannot take place. It seems that Doctrine should check that the field has a default value after it checks if it accepts null, in order to prevent errors on not-null fields with default values that are not passed explicit values.
admin added the Bug label 2026-01-22 14:19:52 +01:00
admin closed this issue 2026-01-22 14:19:52 +01:00
Author
Owner

@doctrinebot commented on GitHub (Oct 17, 2013):

Comment created by @ocramius:

[~spuy767] this is not up to doctrine to check. If your schema enforces non-null fields, so should your object graph do as well.

That means that your setters or constructors should guarantee consistent state of the properties in your entities at any time, regardless of the ORM.

@doctrinebot commented on GitHub (Oct 17, 2013): Comment created by @ocramius: [~spuy767] this is not up to doctrine to check. If your schema enforces non-null fields, so should your object graph do as well. That means that your setters or constructors should guarantee consistent state of the properties in your entities at any time, regardless of the ORM.
Author
Owner

@doctrinebot commented on GitHub (Oct 17, 2013):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Oct 17, 2013): Issue was closed with resolution "Won't Fix"
Author
Owner

@doctrinebot commented on GitHub (Oct 17, 2013):

Comment created by @ocramius:

Also a side-note: the ORM always assumes that your data is valid. It just limits itself to saving and loading it.

@doctrinebot commented on GitHub (Oct 17, 2013): Comment created by @ocramius: Also a side-note: the ORM always assumes that your data is valid. It just limits itself to saving and loading it.
Author
Owner

@doctrinebot commented on GitHub (Oct 17, 2013):

Comment created by spuy767:

Thank you for the clarification, I got a ticket from a dev and our DBA said it was doctrine was throwing the error, but now that I've looked at the Entity, he has no default value assigned to his private variable and doctrine is just doing what it's told.

Clay

@doctrinebot commented on GitHub (Oct 17, 2013): Comment created by spuy767: Thank you for the clarification, I got a ticket from a dev and our DBA said it was doctrine was throwing the error, but now that I've looked at the Entity, he has no default value assigned to his private variable and doctrine is just doing what it's told. Clay
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#3435