feat: upgrading django-history with lots of new migrations.

[awais786]

Issue details edx/edx-arch-experiments#376

https://django-simple-history.readthedocs.io/en/latest/#section-1
Upgrading the package to 3.1.1

The updated package includes some enhancements that introduce new migrations. However, these migrations do not involve any alterations to the existing fields; instead, they are focused on meta changes aimed at improving the ordering functionality.

AlterModelOptions
AlterModelOptions

Related PR jazzband/django-simple-history#862 ( this pr shows the get_latest_by usage )

Similar PR merged in credentials PR

edx-platform generates lots of migrations within edx-app and also in other packages. I have updated other packages also here and these also contains few migrations.

1. feat: upgrading django-simple-history. edx-ora2#2001
2. https://github.com/edx/edx-name-affirmation/pull/140/files
3. build: update django-simple-history package version edx-organizations#324
4. build: update django-simple-history package version edx-proctoring#1140
5. feat: upgrading django-history. edx-enterprise#1820

So far did't bump and release any package. Once finalizing all testing I will merge and release together.

[awais786]

Sandbox with new migrations.

1.   Applying assessment.0008_alter_historicalsharedfileupload_options... OK
2.   Applying blackboard.0017_alter_historicalblackboardenterprisecustomerconfiguration_options... OK
3.   Applying calendar_sync.0003_alter_historicalusercalendarsyncconfig_options... OK
4.   Applying canvas.0032_alter_historicalcanvasenterprisecustomerconfiguration_options... OK
5.   Applying certificates.0035_auto_20230728_1944... OK
6.   Applying consent.0006_alter_historicaldatasharingconsent_options... OK
7.   Applying cornerstone.0029_alter_historicalcornerstoneenterprisecustomerconfiguration_options... OK
8.   Applying course_apps.0002_alter_historicalcourseappstatus_options... OK
9.   Applying course_goals.0009_alter_historicalcoursegoal_options... OK
10.   Applying course_live.0003_alter_historicalcourseliveconfiguration_options... OK
11.   Applying course_modes.0016_alter_historicalcoursemode_options... OK
12.   Applying course_overviews.0029_alter_historicalcourseoverview_options... OK
13.   Applying degreed.0031_alter_historicaldegreedenterprisecustomerconfiguration_options... OK
14.   Applying degreed2.0023_alter_historicaldegreed2enterprisecustomerconfiguration_options... OK
15.   Applying demographics.0004_alter_historicaluserdemographics_options... OK
16.   Applying discussions.0017_alter_historicaldiscussionsconfiguration_options... OK
17.   Applying edx_name_affirmation.0008_alter_historicalverifiedname_options... OK
18.   Applying edx_proctoring.0025_auto_20230727_2112... OK
19.   Applying enterprise.0175_auto_20230726_1615... OK
20.   Applying entitlements.0016_auto_20230728_1944... OK
21.   Applying experiments.0005_alter_historicalexperimentkeyvalue_options... OK
22.   Applying external_user_ids.0006_auto_20230728_1944... OK
23.   Applying grades.0020_alter_historicalpersistentsubsectiongradeoverride_options... OK
24.   Applying instructor_task.0006_alter_historicalinstructortaskschedule_options... OK
25.   Applying moodle.0027_alter_historicalmoodleenterprisecustomerconfiguration_options... OK
26.   Applying organizations.0004_auto_20230727_2054... OK
27.   Applying program_enrollments.0011_auto_20230728_1944... OK
28.   Applying programs.0016_auto_20230728_1944... OK
29.   Applying schedules.0021_alter_historicalschedule_options... OK
30.   Applying split_modulestore_django.0003_alter_historicalsplitmodulestorecourseindex_options... OK
31.   Applying student.0045_auto_20230728_1944... OK
32.   Applying support.0002_alter_historicalusersocialauth_options... OK

[awais786]

Added the variable to avoid indexing on date field.

https://github.com/jazzband/django-simple-history/blob/a768673e0dc5e34e1a81481b0a0d3bfe09a38f8a/docs/historical_model.rst#indexed-history_date

Many queries use history_date as a filter. The as_of queries combine this with the original model's primary key to extract point-in-time snapshots of history. By default the history_date field is indexed. You can control this behavior using settings.py.

#disable indexing on history_date

SIMPLE_HISTORY_DATE_INDEX = False

[rgraber]

Why do we want to disable it?

[rgraber]

Is there any way to separate the upgrades and the migrations, and indeed to separate the migrations from each other? Thinking what would happen if we had to do a rollback

[rgraber]

Why do we want to disable it?

[awais786]

@rgraber https://github.com/jazzband/django-simple-history/blob/master/CHANGES.rst#310-2022-04-09

Added index on history_date column; opt-out with setting SIMPLE_HISTORY_DATE_INDEX (gh-565)

On enabling it will add index and generates more migrations and that will be db level change.

[awais786]

Is there any way to separate the upgrades and the migrations, and indeed to separate the migrations from each other? Thinking what would happen if we had to do a rollback

Yes, its possible.
1: First upgrade the package and merge. But we have to disable the test case which checks new_migrations.
2. In follow up prs add migrations app wise and package wise e.g ( 5 migration for each pr ).

[rgraber]

Is there any way to separate the upgrades and the migrations, and indeed to separate the migrations from each other? Thinking what would happen if we had to do a rollback

Yes, its possible. 1: First upgrade the package and merge. But we have to disable the test case which checks new_migrations. 2. In follow up prs add migrations app wise and package wise e.g ( 5 migration for each pr ).

It sounds like kind of a pain but I do think it is worth it. I'd be nervous about trying to roll this back all at once

[iamsobanjaved]

Closing this as this got implemented in chunks