Hello,
I would like to understand the argument that lead to the fact that indexes associated with constraints (primary keys, foreign keys and unique constraints) are explicitly defined on the code to be interpreted as not a change and consequently no be a part of the ChangeLogFile and therefore no SQL is generated for such differences.
I’ve noticed this behaviour when comparing one database with a reference one. The reference one as explicitly defined indexes for each constraint. This way, one has more control over the model, having the possibility of defining index names and specific location for storage.
In my example, I have on my reference database a table XXX with an index xxx_fk1 and a foreign key xxx_fk1 and nothing on the same table of the compared database. The “diffChangeLog” command only outputs the creation of the foreign key xxx_fk1.
After analysis of the code, I noticed that the “DiffResult” class is the responsible for this behaviour because while iterates through all the changes, it goes out of the loop if the change is an index associated with such constraint types. Removing this logic and executing again liquibase with the “diffChangeLog” command creates output both fot he creation of the index and subsequently the foreign key.
So, assuming that there is a specific reason for this behaviour, I would like to ask how can I override or extend this implementation. From what I’ve read and understand on the Extensions documentation, it’s only possible to think in extend or override the liquibase starting from the changelog file and this tweak I want to make its before this stage. So how can it be done?
Thank you very much for your support.
The handling of indexes for backing FKs and PKs vs. stand alone indexes isn’t correct currently because for time purposes I had to push going through the diff logic out of the 2.0 release in order to get it released. I and/or others need to go through the diff logic and apply the same extension support/API analysis that I did to the rest of the liquibase codebase for 2.0.
The biggest problem is there isn’t a well defined way to handle cross-database differences with the diff tool. The indexes you mention, for example, are ignored in the code because there are many databases which will fail if you attempt to create the foreign key and the index backing it. A goal of the diff tool is to be able to compare different database types for differences, but what constitutes a difference in structure, and which is a difference in implementation? It gets ugly quickly.
The plan is to look hard at how the diff tool works for 2.1, but I have been falling behind on 2.0 and have not gotten a chance to even start on 2.1 yet.
If you are interested in helping refactor the diff support, that would be great. Otherwise, you will have to work around how it works in 2.0 until 2.1 is released.
Nathan
The hope is to push that logic to configuration stored within each database type, so that the MysqlDatabase code knows to ignore indexes, but the OracleDatabase knows it needs to.
Nathan
Maybe a good option would be to leave such decisions (like this one of letting create backing indexes and others) to the user, letting it be an optional parameter one could pass.
In my specific case, Informix by default will create an internal index for a constraint, if none exists for the same columns. Then the only way to drop such index is to drop the constraint. But if one creates the index before the constraint creation, then no error is generated. Let me say also that it was told me that from version 11.70 (currently 11.50), the behaviour of automatically create an index for a constraint can be avoided by user definition.
For the diff refactoring, I am far from being an expert. Although, I will give it a look and see as far as I can go.
Cheers!
