Feature #15141
closedExtension Manager: Show conflicting DB table definitions
0%
Description
When there are two extensions installed that have different SQL definitions for the same table, there are conflicts.
Example:
Extension A defines the title field of table xyz as "tinytext". When it is updated, it offers to change the table.
Extension A defines the title field of table xyz as a different type. When it is updated, it offers to change the table, too.
This may break something and should be automatically recognized and prevented.
I've seen this with the static_info_tables extension which conflicts with another one.
(issue imported from #M1705)
Updated by Karsten Dambekalns over 18 years ago
I see it like this: the changes that are about to me made are shown, the admin should be able to make sense of this. It may well be, that the tables are there, but the extension has long been removed, what then?
If there is really a conflict, the extensions authors should declare this in the dependencies, IMHO.
Updated by Oliver Klee over 18 years ago
I agree that conflicts should be stated in the dependencies.
Yet, we cannot solely rely on this as this would require each extension author to know the table changes of each other extension (at least concerning common tables like the static info table).
I opened the bug because of two extensions that conflict in their table definitions although one extension requires the other: static_info_tables and sr_static_info. Each time I update one of them, they offer to update some tables. I've experienced that for one of these extensions, updating the tables breaks yet other extensions, and so I need to remember not to click "Make updates" when updating one of these two extensions.
For all other extensions, using "Make updates" for the tables is required for the update to work.
I don't know exactly how to prevent problems like this, but I don't like how this currently works. This button shouldn't break anything when it usually is required to not break anything.
Updated by Steffen Kamper almost 14 years ago
i can't see a simple solution, extensions may change any field they want, and if they don't know where the conflict happens, they don't use the conflict array.
This should reported to the authors so they can adjust their dependencies.
Updated by Helmut Hummel about 13 years ago
- Priority changed from Should have to Could have
- Target version deleted (
0) - TYPO3 Version changed from 3.8.0 to 4.5
- PHP Version deleted (
4)
Updated by Helmut Hummel about 13 years ago
- TYPO3 Version changed from 4.5 to 4.7
Updated by Susanne Moog over 10 years ago
- Status changed from New to Needs Feedback
Hi,
I don't currently see a solution for this - especially as we can't know whether the changes really conflict or just change the same fields. For example a change from core=varchar(10) to extension a=varchar(20) to extension b=varchar(55) would probably not break a thing.
I'd prefer to leave these choices to the extension authors and admins out there. If you think differently please comment what your solution would look like.
Regards,
susi
Updated by Oliver Klee over 10 years ago
After thinking about this for a bit, I'm also fine with closing this ticket as "wont't fix".
Updated by Alexander Opitz over 10 years ago
- Status changed from Needs Feedback to Rejected