CURRENT_TIMESTAMP not possible anymore as default value

[holtkamp]

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?

[Ocramius]

See:

#6383
#6346

[holtkamp]

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?

[Ocramius]

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/ 24b4ebf/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 <#6698 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJakPwdTSl1Ol7Lvjwl0fI__sRsufPeks5shFlTgaJpZM4PSbOU> .

[Ocramius]

@holtkamp see doctrine/dbal#2855 for example tests BTW

[holtkamp]

@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]

Aah, just checked out the master of DBAL, seems already be resolved by doctrine/dbal#2835