doctrine/archived-orm
1
0
Fork 0
mirror of https://github.com/doctrine/orm.git synced 2026-03-24 06:52:09 +01:00
Code Issues 5.3k Packages Projects Releases 100 Wiki Activity

CURRENT_TIMESTAMP not possible anymore as default value #5695

New Issue
Closed
opened 2026-01-22 15:14:50 +01:00 by admin · 6 comments
admin commented 2026-01-22 15:14:50 +01:00
Owner
Copy Link

Originally created by @holtkamp on GitHub (Sep 10, 2017).

This mapping used to work < 2.5 to have the database use CURRENT_TIMESTAMP as a default value for a DateTime property:

<field name="creationTimestamp" type="datetime" column="creation_timestamp" nullable="false">
  <options>
    <option name="default">CURRENT_TIMESTAMP</option>
  </options>
</field>

It resulted in SQL DDL like:

creation_timestamp DATETIME DEFAULT CURRENT_TIMESTAMP

As of 2.5 it seems the default value seems to be "properly" respected and result in:

creation_timestamp DATETIME DEFAULT 'CURRENT_TIMESTAMP'

When using MySQL such SQL returns an error: Invalid default value for 'creation_timestamp'

This was also mention on StackOverflow.

Not sure if the new 'behaviour' is intended behaviour?

Originally created by @holtkamp on GitHub (Sep 10, 2017). This mapping used to work < `2.5` to have the database use `CURRENT_TIMESTAMP` as a default value for a DateTime property: ```xml <field name="creationTimestamp" type="datetime" column="creation_timestamp" nullable="false"> <options> <option name="default">CURRENT_TIMESTAMP</option> </options> </field> ``` It resulted in SQL DDL like: ```sql creation_timestamp DATETIME DEFAULT CURRENT_TIMESTAMP ``` As of `2.5` it seems the default value seems to be "properly" respected and result in: ```sql creation_timestamp DATETIME DEFAULT 'CURRENT_TIMESTAMP' ``` When using MySQL such SQL returns an error: `Invalid default value for 'creation_timestamp'` This was also mention on [StackOverflow](https://stackoverflow.com/questions/7698625/doctrine-2-1-datetime-column-default-value#comment72902624_38202540). Not sure if the new 'behaviour' is intended behaviour?
admin closed this issue 2026-01-22 15:14:50 +01:00
admin commented 2026-01-22 15:14:51 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Sep 10, 2017):

See:

https://github.com/doctrine/doctrine2/issues/6383
https://github.com/doctrine/doctrine2/issues/6346

@Ocramius commented on GitHub (Sep 10, 2017): See: https://github.com/doctrine/doctrine2/issues/6383 https://github.com/doctrine/doctrine2/issues/6346
admin commented 2026-01-22 15:14:51 +01:00
Author
Owner
Copy Link

@holtkamp commented on GitHub (Sep 10, 2017):

Mm, sorry, thought I searched properly...

I found the cause of this 'change' in behaviour during SQL generation. To enable support for microseconds, I created a Custom DBAL Type and registered it using Type::overrideType(Type::DATETIME, \MyCustomDateTimeClass::class). When I disable this, the SQL generation works properly again.

The name of the Type to be used is datetime (lowercase) as defined here: 24b4ebf034/lib/Doctrine/DBAL/Types/Type.php (L42)

However when getDefaultValueDeclarationSQL is invoked, it checks for Type DateTime (CamelCase): 24b4ebf034/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php (L2284)

Could this (lowercase versus CamelCase) be the source of this 'change' in generated SQL?

@holtkamp commented on GitHub (Sep 10, 2017): Mm, sorry, thought I searched properly... I found the cause of this 'change' in behaviour during SQL generation. To enable support for microseconds, I created a Custom DBAL Type and registered it using `Type::overrideType(Type::DATETIME, \MyCustomDateTimeClass::class)`. When I disable this, the SQL generation works properly again. The name of the Type to be used is `datetime` (lowercase) as defined here: https://github.com/doctrine/dbal/blob/24b4ebf034f346d20ce81338e8bb2b6d086c19e1/lib/Doctrine/DBAL/Types/Type.php#L42 However when `getDefaultValueDeclarationSQL` is invoked, it checks for Type `DateTime` (CamelCase): https://github.com/doctrine/dbal/blob/24b4ebf034f346d20ce81338e8bb2b6d086c19e1/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L2284 Could this (lowercase versus CamelCase) be the source of this 'change' in generated SQL?
admin commented 2026-01-22 15:14:54 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Sep 12, 2017):

Eh, sorry, not following you: would need a test case to understand the
issue. So far, though, we don't support expressions as default values

On 10 Sep 2017 23:49, "Menno Holtkamp" notifications@github.com wrote:

Mm, sorry, thought I searched properly...

I found the cause of this 'change'. To enable support for microseconds, I
created a Custom DBAL Type and registered it using
Type::overrideType(Type::DATETIME,
\MyCustomDateTimeClass::class). When I disable this, the SQL generation
works properly again.

The name of the Type to be used is datetime (lowercase) as defined here:
https://github.com/doctrine/dbal/blob/24b4ebf034f346d20ce81338e8bb2b
6d086c19e1/lib/Doctrine/DBAL/Types/Type.php#L42

However when getDefaultValueDeclarationSQL is invoked, it checks for Type
DateTime (CamelCase): https://github.com/doctrine/dbal/blob/
24b4ebf034f346d20ce81338e8bb2b6d086c19e1/lib/Doctrine/DBAL/
Platforms/AbstractPlatform.php#L2284

Could this (lowercase versus camelcase) be the source of this 'change' in
generated SQL?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6698#issuecomment-328374467,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakPwdTSl1Ol7Lvjwl0fI__sRsufPeks5shFlTgaJpZM4PSbOU
.

@Ocramius commented on GitHub (Sep 12, 2017): Eh, sorry, not following you: would need a test case to understand the issue. So far, though, we don't support expressions as default values On 10 Sep 2017 23:49, "Menno Holtkamp" <notifications@github.com> wrote: Mm, sorry, thought I searched properly... I found the cause of this 'change'. To enable support for microseconds, I created a Custom DBAL Type and registered it using Type::overrideType(Type::DATETIME, \MyCustomDateTimeClass::class). When I disable this, the SQL generation works properly again. The name of the Type to be used is datetime (lowercase) as defined here: https://github.com/doctrine/dbal/blob/24b4ebf034f346d20ce81338e8bb2b 6d086c19e1/lib/Doctrine/DBAL/Types/Type.php#L42 However when getDefaultValueDeclarationSQL is invoked, it checks for Type DateTime (CamelCase): https://github.com/doctrine/dbal/blob/ 24b4ebf034f346d20ce81338e8bb2b6d086c19e1/lib/Doctrine/DBAL/ Platforms/AbstractPlatform.php#L2284 Could this (lowercase versus camelcase) be the source of this 'change' in generated SQL? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/doctrine/doctrine2/issues/6698#issuecomment-328374467>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakPwdTSl1Ol7Lvjwl0fI__sRsufPeks5shFlTgaJpZM4PSbOU> .
admin commented 2026-01-22 15:14:54 +01:00
Author
Owner
Copy Link

@Ocramius commented on GitHub (Sep 12, 2017):

@holtkamp see https://github.com/doctrine/dbal/pull/2855 for example tests BTW

@Ocramius commented on GitHub (Sep 12, 2017): @holtkamp see https://github.com/doctrine/dbal/pull/2855 for example tests BTW
admin commented 2026-01-22 15:14:57 +01:00
Author
Owner
Copy Link

@holtkamp commented on GitHub (Sep 12, 2017):

@Ocramius ok thanks

would need a test case to understand the issue

Summary: when overriding a DBAL Type (such as DateTime) the DefaultValueDeclarationSQL is not recognized properly anymore, so it is not used as an expression but as a string, resulting in invalid SQL. This probably justifies a separate issue, so I will close this one.

Since we dropped using default values at database level (should be ad Domain Model level), the priority has decreased a bit, but will try to find some time to come up with a test.

@holtkamp commented on GitHub (Sep 12, 2017): @Ocramius ok thanks >would need a test case to understand the issue Summary: when overriding a DBAL Type (such as DateTime) the DefaultValueDeclarationSQL is not _recognized_ properly anymore, so it is not used as an expression but as a string, resulting in invalid SQL. This probably justifies a separate issue, so I will close this one. Since we dropped using default values at database level (should be ad Domain Model level), the priority has decreased a bit, but will try to find some time to come up with a test.
admin commented 2026-01-22 15:14:58 +01:00
Author
Owner
Copy Link

@holtkamp commented on GitHub (Sep 12, 2017):

Aah, just checked out the master of DBAL, seems already be resolved by https://github.com/doctrine/dbal/pull/2835

@holtkamp commented on GitHub (Sep 12, 2017): Aah, just checked out the master of DBAL, seems already be resolved by https://github.com/doctrine/dbal/pull/2835
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BC Break
Bug
Can't Fix
Deprecation
Documentation
DQL
Duplicate
Failing Test
Hacktoberfest
Improvement
Improvement
Incomplete
Invalid
Missing Tests
New Feature
PR Created
pull-request
Mirrored from GitHub Pull Request
 Question
Regression
Status: Waiting feedback
Waiting feedback
WIP
Won't Fix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
admin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5695
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?