Feature #97524
closed
Make it possible to run UPDATE sql statements within ext_tables_static+adt.sql in SqlReader and SchemaMigrator
0%
Description
SqlReader can currently only read INSERT and CREATE TABLE statements, but not UPDATE statements from ext_tables_static+adt.sql.
SchemaMigrator can currently only run INSERT and CREATE TABLE statements, but not UPDATE statements.
The extension static_info_tables_* therefor need an own solution to update existing company records and add translations. Both, the static_info_tables_* extensions could profit from this feature but also the TYPO3 testing framework which also doesn't support run the UPDATE statements and therefor functional tests which read translated country names can't be tested like translated country names in fluid templates for example.
See: https://github.com/TYPO3/testing-framework/issues/359 and https://github.com/TYPO3/testing-framework/blob/d03dbaf10c680b74439fdb18ada31853bcda02b5/Classes/Core/Testbase.php#L765-L766
Updated by Christian Kuhn over 2 years ago
- Status changed from New to Needs Feedback
The ext_tables_static+adt.sql API is pretty ugly and we shouldn't extend it any further. It's bad enough that it blindly runs the INSERT statements. extensionmanager already has this quirk to remember the state in registry to see if it should run or not. All in all, that's should mid-term probably vanish altogether in the core and substituted with some more reliable db-row-migration functionality, however it would look like.
Looking at static_info_tables and static_info_tables_de, the involved code does not look really reliable, either. Note class.tx_update.php from static_info_tables_de is no longer supported by core, either. I think these extensions would be better of by creating an upgrade wizard for this kind of rather complex db-priming stuff and to document people should call that wizard after installing the extension. At least for now.
I thus think we shouldn't add more headaches to this area for the moment, but instead look forward to a more solid overall solution. I'm actually unsure if core would have to provide an API for that at all: With composer, an extension could register a script do manage db state of these tables, for instance (just a thought).
I'd like to close this issue as rejected. Is this fine with you?
Updated by Stefan Bürk over 2 years ago
Ack. Let's reject this issue.
UpdateWizards opens the ability to handle this properly on your own and let you control all you need. No need to create an additional API again for it.
Updated by Christian Kuhn over 2 years ago
- Status changed from Needs Feedback to Rejected