It's not possible to create tables with datetime fields using the schema api if you want to have a default value of now() or current_timestamp. This happens because all strings are escaped with ' before going to the database. Database function calls like now() do not work if escaped. The attached patch allows now() to be used for datetime fields.

CommentFileSizeAuthor
patch.txt2.73 KBwienczny

Issue fork drupal-215821

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Pancho’s picture

Pancho
Location UTC+2 🇪🇺 EU
CreditAttribution: Pancho commented
Category: feature » bug

This is a bug, as it's torpeding usage of the Schema API and therefore endangering the dbs abstraction.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

what about current_timestamp? any others like this?

traxer’s picture

traxer CreditAttribution: traxer commented
Category: bug » feature
Status: Needs review » Needs work

The behaviour of Drupal's database system does not deviate from what is documented. Also, having the database take care of setting the time by itself is nice to have, but not critical to the usage of a database abstraction layer. So this is a feature request.

The MySQL implementation of the Schema API implements the datetime field using MySQL's DATETIME type. That type does not support automatic initializiation/update to the current time.

MySQL's type TIMESTAMP supports automatic initializiation/update to the current time. Switching from DATETIME to TIMESTAMP is not an option, though:

  • TIMESTAMP behaves differently in MySQL versions 4.1, 4.1.2, 4.1.3, 4.1.6
  • The first TIMESTAMP column in a table behaves different than other TIMESTAMP columns in that table.

See http://dev.mysql.com/doc/refman/4.1/en/timestamp.html for details.

ScoutBaker’s picture

ScoutBaker CreditAttribution: ScoutBaker commented
Version: 6.x-dev » 7.x-dev

As a feature request, I'm moving this to D7.

Crell’s picture

Crell CreditAttribution: Crell commented
Version: 7.x-dev » 8.x-dev

And now to D8.

geerlingguy’s picture

geerlingguy CreditAttribution: geerlingguy commented

And now I subscribe.

dozymoe’s picture

dozymoe CreditAttribution: dozymoe commented

0.0

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

running into this issue currently. So this appears to be an issue that looking for a solution that tells the DB to properly set a default value when the row is created in the DB.

But I need a solution now. Can I just set the type of the field to datetime and set it's value on node_create?

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented
Version: 8.x-dev » 6.x-dev

7.x and 8.x do *not* support datetime fields.

BAM5’s picture

BAM5 CreditAttribution: BAM5 commented
Version: 6.x-dev » 8.x-dev

Datetime fields are supported, just not as a 'type' type. You have to specify it through the 'mysql_type' and equivalent properties for other database drivers. Besides, who says that datetime fields won't ever be supported in the future making this request completely relevant?

Also, the now() function does not work for inserting values, now() is once again turned into a string quotation.

smartango’s picture

smartango CreditAttribution: smartango commented

being for d8, what about this schema definition:

...
'fields' => array(
  'id' => array(
    'type' => 'int',
    'length' => 11,
    'not null' => true,
    'default' => 1,
  ),
  'timestamp' => array(
    'type' => 'timestamp',
    'not null' => true,
    'default' => function(){return 'CURRENT_TIMESTAMP';},
    'on update' => function(){return 'NOW()';},
  ),
...

then in core code:

if( is_object($schema['default']) && ($schema['default'] instanceof Closure) ) $default = $schema['default']();
else $default = ESCAPE($schema['default']);
...

I put 'on update' because it is present in mysql, how to manage this? any plan? (want do/dont want ..)

- EDIT: is_callable does not really work correctly
- EDIT 2: style
- EDIT 3: I neither look at code, what is ESCAPE?

Crell’s picture

Crell CreditAttribution: Crell commented

The schema array is currently serialized, and anonymous functions cannot be serialized.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

AaronBauman’s picture

AaronBauman
he/him
CreditAttribution: AaronBauman at Message Agency commented
Issue summary: View changes

Shall we call this "won't fix" then?

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hkirsman’s picture

hkirsman CreditAttribution: hkirsman commented

+1 - would be nice to have!

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

DrupalDope’s picture

DrupalDope CreditAttribution: DrupalDope commented

I need this too.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Bhanu951’s picture

Bhanu951 CreditAttribution: Bhanu951 as a volunteer commented
Version: 9.4.x-dev » 10.1.x-dev

Bhanu951 opened merge request !2949

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.