mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
DDC-3040: doctrine:schema:update datetimetz field type not null #3775
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Mar 19, 2014).
Originally assigned to: @beberlei on GitHub.
Jira issue originally created by user ruscon:
I have some fields like
@ORM\Column -> nullable=false
In database this field already not null
But when i execute in console:
{quote}
./app/console doctrine:schema:update --dump-sql --env=dev
{quote}
answer:
{quote}
ALTER TABLE test CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
{quote}
If I change datetimetz to datetime type fot $expiredAt
and execute:
{quote}
./app/console doctrine:schema:update --dump-sql --env=dev
{quote}
answer:
{quote}
ALTER TABLE test CHANGE added_at added_at DATETIME NOT NULL;
{quote}
@doctrinebot commented on GitHub (Apr 5, 2014):
Comment created by ruscon:
have some news about this problem ?
@doctrinebot commented on GitHub (Apr 6, 2014):
Comment created by @ocramius:
[~ruscon] does the DDL update statement persist in the diffs even after running it?
@doctrinebot commented on GitHub (Apr 6, 2014):
Comment created by ruscon:
or if i use additional bundle
@doctrinebot commented on GitHub (Apr 7, 2014):
Comment created by @deeky666:
I assume from the syntax that you are using MySQL. MySQL does not have a native type for DateTimeTz, therefore the mapping always falls back to the native DATETIME type. See the DBAL documentation (footnote 15): http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#mapping-matrix
The problem here is not the nullable flag but the type you use. Therefore you get the irrgeular update statements from the schema tool. Use Doctrine's "datetime" type instead and you'll be fine. You won't be able to store time zone information for a date time in MySQL anyways as it does not have a type for this.
@doctrinebot commented on GitHub (Apr 7, 2014):
Comment created by ruscon:
Steve Müller, you right. Thanks.
@doctrinebot commented on GitHub (Apr 7, 2014):
Issue was closed with resolution "Can't Fix"