Interplay between foreign keys and the include-objects/exclude-objects flags

[Dzeri96]

Search first

• I searched and no similar issues were found

Description

When running the generate-changelog command with the --include-objects/--exclude-objects flags, foreign key constraints referencing non-included objects are still present in the created changelog.

This is not a huge problem when generating SQL scripts with separate ALTER TABLE statements, but otherwise I think it might prevent the application of changelogs entirely.

Steps To Reproduce

Create two tables in the DB, with table A having a foreign key constraint referencing table B. Run liquibase generate-changelog --include-objects="A".

Expected/Desired Behavior

I see two ways to solve this:

• Simply ignore foreign key constraints to objects which are not included in the export.
• Have a way to recursively include all referenced objects until the minimal number of them are included, such that the original set of objects has the same referential integrity as the source DB schema.

Liquibase Version

4.26.0

Database Vendor & Version

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0

Liquibase Integration

CLI

Liquibase Extensions

No response

OS and/or Infrastructure Type/Provider

Windows Server 2012 (I know...)

Additional Context

No response

Are you willing to submit a PR?

• I'm willing to submit a PR (Thank you!)

[MalloD12]

Hi @Dzeri96,

It sounds better to me to ignore the foreign key constraint (or any other change type) than recursively looking for the objects to either include or exclude. Do you know the place where to start looking at?

Thanks,
Daniel.

[Dzeri96]

@MalloD12 I haven't looked at the code yet, but it should be pretty simple to terminate a recursive branch if the next child is not in the 'include' list. I think we can have the best of both worlds, but that's just theory.

[MalloD12]

Hey @Dzeri96,

If I didn't see it wrong our guy should be StandardObjectChangeFilter class. I was thinking if we were between a non-recursive approach and one recursive I would go for the first in case recursion could have a negative performance impact, but if it's a simple recursion I'm fine with it.

Thanks,
Daniel.

[Dzeri96]

@MalloD12 I just assumed that recursion is already part of the process, as I get a stack overflow if I don't increase the stack size when running liquibase on our company's DB. If this is a welcome feature, which seems like it is, I'll try to make a PR. Can't really promise when but I'll definitely keep it in my backlog.

[MalloD12]

Sure, feel free to submit that PR when you have a chance. We will be happy to review it and test it.

Thanks!