Table tx_dpf_domain_model_documenttype can't be created in MySQL 5.7 because 'virtual' is now reserved

[lutzhelm]

MySQL added virtual as reserved word in version 5.7.6. In effect, the table tx_dpf_domain_model_documenttype can't be created via extension installation from this version on.

EDIT:
https://dev.mysql.com/doc/refman/5.7/en/keywords.html#keywords-5-7-detailed-V
VIRTUAL (R); added in 5.7.6 (reserved)

[claussni]

Solution would be to rename the model field virtual to something expressing the fact that document types which this flag do need to have attachments. Or would quoting the key word virtual be a solution?

What do think, @haogatyp?

[haogatyp]

I would suggest to rename it into type_abstract.

[claussni]

What happens to existing data when renaming the field?

[haogatyp]

The database field is also renamed. When updating the extension, the migration of the field must then be initiated via Installation Tool->Database compare (Alter Table). If this is not possible, a separate update script must be developed.

[haogatyp]

In the Fedora repository, the field should certainly not be renamed, so you do not have to migrate. Therefore, it might be better to change the field in TYPO3 to type_virtual. So it remains traceable in the code, regarding the interface between TYPO3 and repository.

[claussni]

TYPO3 database analyzer tool option does not seem to be very helpful:

ALTER TABLE tx_dpf_domain_model_documenttype CHANGE virtual zzz_deleted_virtual tinyint(1) unsigned NOT NULL default '0';

[claussni]

I consider MySQL 5.7 support an enhancement. Given the necessary code changes and data migration issues it's actually not an easy fix to do.

[claussni]

Suggestion:

1. Release providing an update script for running on MySQL 5.6 for moving the field.
2. Next release removing the problematic field definition.

[claussni]

@haogatyp Can we address this issue now for 4.x and later provide migration for 3.x branches?

[haogatyp]

Yes, this should be possible.