Clever way of adding uuid column
At the moment, a whole bunch of code taken from Extension Manager and/or Install Tool has been duplicated in EXT:identity to be able to add the 'uuid' column to all relevant tables.
So the goal is:
- Avoid duplicating code
- Do not perform SQL queries on non-existing columns
- Be consistent and make the Install Tool "know" about those columns
My idea would be to forget the concept of UPDATE! and use an EM hook instead (available since 4.5):
I think that if EXT:identity implements it and dynamically (re-)generates its own ext_tables.sql file by specifying that the 'uuid' column should be added to all relevant tables then it will be much more stable (columns are there and not candidate for removal any more!) and the existing "native" TYPO3 methods will be executed without having to reinvent the wheel to add the missing column.
Furthermore, in order to prevent a possible unwanted commit to EXT:identity's repository, easiest way will be to put ext_tables.sql in the SVN ignore list and hard-code the table that is currently specified.
#2 Updated by Thomas Maroschik over 8 years ago
- Status changed from New to Accepted
- Priority changed from Should have to Must have
This looks great, but has 2 issues in my opinion:
- I would rather put the ext_tables.sql somehow to typo3temp or typo3conf. This would make ext:identity inclusion through svn:externals easier.
- I'll see what I can do.
- If you install a new extension you have to check either ext:identity or the install tool for updates. The current way tried to make it as transparent as possible, although I didn't succeed too much.
- Will try to think about this one.
#3 Updated by Thomas Maroschik over 8 years ago
Just noticed that the install tool uses the $GLOBALS['TYPO3_LOADED_EXT'] array and the according extension paths in there. This is something I could manipulate to get the ext_tables.sql paths configured for install tool.
The EM should use this path information too in tx_em_install->checkDBupdates as it builds the path by itself. Or is the extension not inside this array upon installation?
#4 Updated by Thomas Maroschik almost 8 years ago
Do you think we solved it "OK" now?
Lots of XClasses and code duplication has been removed and integration solved by hooks introduced in 4.6.
The only way we use the duplicate code right now is in the update message. I think it's fine there, as it does just triggered upon calling the extensions configuration page.