Enhancement: Provide Squashed Migration for `auditlog` App

[KSreethul]

Description

Currently, the auditlog app contains multiple sequential migration files (0001 → 0017). While this works well for incremental upgrades, fresh installations are required to execute all migration files individually.

This enhancement proposes introducing a squashed migration that consolidates the existing migrations into a single migration for new installations.

Proposed Improvement

• Generate a squashed migration:

  python manage.py squashmigrations auditlog 0001 0017

• Provide a consolidated migration file (e.g., 0001_squashed.py)

• Maintain backward compatibility using Django’s replaces = [...] mechanism

• Ensure existing installations continue to upgrade without disruption

Benefits

1. Faster Fresh Installations

   • New setups will execute only one migration instead of 17.
   • Reduces migration time during project initialization.

2. Cleaner Migration Structure

   • Less migration clutter.
   • Easier long-term maintenance.

3. Improved Developer Experience

   • Simpler onboarding.
   • Clearer migration history.

4. CI/CD Optimization

   • Reduces migration overhead in automated deployments and containerized environments.

This improvement would especially benefit projects like Horilla CRM, where frequent fresh deployments are performed across multiple environments.

[ajnasajnas1234]

We’re facing the same issue with sequential migrations (0001–0017) in the auditlog app during fresh installations, which increases setup time in frequently deployed environments.

Adding a squashed migration while maintaining backward compatibility using replaces = [...] is a clean and scalable solution. It will speed up fresh installs, reduce migration clutter, and improve CI/CD efficiency.

Please proceed with reviewing and merging this PR so we can move forward with this improvement.

[NihanaSherinP]

We’ve encountered the same concern with the sequential migrations (0001 → 0017) in the auditlog app, particularly during fresh project setups. Executing each migration file individually adds unnecessary overhead, especially in environments where deployments and reinitializations happen frequently.

Creating a squashed migration (such as 0001_squashed.py) while preserving backward compatibility through Django’s replaces = [...] option is a practical and maintainable solution. This approach would:

Minimize migration execution time for new installations

Simplify the migration structure

Improve maintainability over time

Enhance CI/CD efficiency and container startup performance

Overall, consolidating these migrations would provide a cleaner setup process and better developer experience across multiple environments.

Kindly review and merge the proposed pull request to implement this improvement.

[2ykwang]

@KSreethul I don’t see evidence that the current migrations actually cause problems. Could you share any concrete issues or numbers? For example, how slow is it in your setup?

also, several near-identical comments were posted within ~10 minutes, and the account names look quite similar. If this is truly an issue that needs to be addressed, feedback presented in this way doesn’t seem helpful for actually solving the problem.

[KSreethul]

Hi @2ykwang,

Thanks for your response.

Just to clarify — this is not being raised as a problem or bug, but purely as an enhancement to improve fresh installation efficiency and long-term maintainability.

In our workflow, while working on Horilla CRM (https://github.com/horilla-opensource/horilla-crm) and related deployments, we frequently perform fresh setups across development, staging, CI pipelines, and containerized environments. During these setups, running 17 sequential migrations (0001 → 0017) for the auditlog app adds avoidable overhead. It doesn’t cause errors or functional issues — it’s simply an optimization opportunity.

The proposal follows Django’s recommended approach:

python manage.py squashmigrations auditlog 0001 0017

with proper use of:

replaces = [...]

This ensures:

• Existing installations remain completely unaffected
• Only new installations benefit from the consolidated migration
• Migration history becomes cleaner and easier to maintain

I’ve already submitted a pull request implementing the squashed migration with full backward compatibility.

Regarding the similar comments — multiple team members involved in repeated deployments experienced the same setup overhead and shared their feedback individually. There was no intention to create noise, only to support the enhancement based on real-world usage.

If needed, I’m happy to share timing comparisons from our environment.

Thanks again for reviewing this enhancement proposal.