For the record, the fact you have to rename the index is exactly why the bug in the schema parser needs to be fixed. You should not have to version suffix table indexes.

@mbabker Yes, I know. But it is not a bug, it is missing by design. That's why I did not fix it yet, it is a bigger thing.

Attention, PR is not ready yet, changes in joomla.sql are missing. But you can already apply the PR and run the DB fixer for testing the schema updates are working.

It's a bug if it's missing this critical of a feature 😉

(And yeah, I realize fixing the database code is a lot more effort than it's sometimes worth, but still have to make it known I hate hacky fixes to work around a deeper underlying problem)

ALTER TABLE #__template_styles DROP INDEX idx_client_id_home; may fail because the index doesn't exists on direct update

@mbabker I absolutely agree with you about the issue, but it is not just a bug fix. It needs a redesign of the schema checker. That's why we now have to use the ugly hacks, we don't have the time now to fix the schema checker.

@HLeithner Not sure. For postgres I have used "IF EXISTS", that should be ok. For the other DB types we don't have that yet. I have to check that.

Hint for testers: Link to modified update package in description has changed, package has been updated by latest changes on this PR.

@HLeithner Not sure. For postgres I have used "IF EXISTS", that should be ok. For the other DB types we don't have that yet. I have to check that.

Something like this for MySQL can help?
(only some new versions of mysql like MariaDB supports IF EXIST for indexes)

SET @idxexist := (SELECT COUNT(*) FROM information_schema.statistics WHERE table_name = '#__template_styles' AND index_name = 'idx_client_id_home' AND table_schema = database());
SET @sqlrmidx:= if( @idxexist > 0, 'SELECT ''INFO: Index already exists.''', 'ALTER TABLE #__template_styles DROP INDEX idx_client_id_home');
PREPARE rmidx FROM @sqlrmidx;
EXECUTE rmidx;

@simbus82 That would work for the installer when doing the update, but the database schema checker would be confused. we found other way. pr is ready for being tested.

@alikon @twister65 Can you test this PR for postgres? I gotta go sleep now.

I have tested this item ✅ successfully on 71252b7

On a mariadb setup this worked for me on the downloads.joomla.org backup I have (which experienced this issue) going from both 3.9.8 backup to this proposed 3.9.10 directly and also going from 3.9.8 to 3.9.9 and then to the proposed 3.9.10. In both cases the schema checker also didn't show any issues.

not able to do a full test on postgresql ... just a quick test on SQL Fiddle

I have tested this item ✅ successfully on 71252b7

This corrects the issue here with mysqli

I have tested this item ✅ successfully on 71252b7

This corrects the issue here with mysqli

Status "Ready To Commit".

@alikon not good enough for a postgresql test for this I'm afraid. We need to be sure our index's are being preserved. Anyone else here able to do a postgresql test before this is merged

Set back on pending by comment of @wilsonge above.

i know, but cannot help today more than this ...

https://docs.joomla.org/Tables/template_styles i've updated this page to state it's a varchar and noted the type of the database

@alikon are you able to at least test it with the index's applied to that table rather than just with the table structure? I installed postgres with brew last night onto my macbook but didn't get time to set up a full joomla install - and won't be able to until tonight

sorry @wilsonge & all, i'm able to do only some spot SQL Fiddle

I tested all postgresql scenarios with postgresql 9.6 and worked now.

thx richard