• 
      

    Update the SiteConfiguration and SCMTool setup after DB install/upgrade.

    Review Request #10606 — Created June 22, 2019 and submitted

    Information

    Review Board
    release-4.0.x

    Reviewers

    We create and manage a SiteConfiguration and register SCMTools when
    syncing the database (which happens when creating a site, upgrading it,
    or during some unit test runs, when not just rolling back transactions).
    This is done by listening to a syncdb operation and hooking in at the
    right moment.

    With Django 1.11, we need to react to migrate events instead. This
    works in a similar way, and is run at similar times. This change adds
    support for both syncdb and migrate, while we're still in a
    transition phase.

    Ideally, we'd move to performing this after an evolve operation, which
    would ensure we only bump the database version in the siteconfig or
    register tools when we're completely done with an installation or
    upgrade. This is a Nice To Have, but not required. Doing this properly
    would involve cleaning up how our SCMTools are registered during test
    runs (we currently register via both fixtures and the management
    command), and ensuring creation of a SiteConfiguration during all test
    runs. This is a clean-up task for the future.

    This change also nukes the old baseline evolution schema, which was
    required back in pre-1.0 to help establish a base set of evolutions and
    serialized model data so that unwanted changes aren't applied. We don't
    need this at all anymore, and Django Evolution is smart enough to handle
    more of those sorts of situations anyway. Removing this simplifies a
    decent amount of our setup and startup.

    Unit tests pass on Django 1.6 and 1.11.

    Successfully created new databases and upgraded existing ones.

    Summary ID
    Update the SiteConfiguration and SCMTool setup after DB install/upgrade.
    We create and manage a `SiteConfiguration` and register `SCMTools` when syncing the database (which happens when creating a site, upgrading it, or during some unit test runs, when not just rolling back transactions). This is done by listening to a `syncdb` operation and hooking in at the right moment. With Django 1.11, we need to react to `migrate` events instead. This works in a similar way, and is run at similar times. This change adds support for both `syncdb` and `migrate`, while we're still in a transition phase. Ideally, we'd move to performing this after an `evolve` operation, which would ensure we only bump the database version in the siteconfig or register tools when we're completely done with an installation or upgrade. This is a Nice To Have, but not required. Doing this properly would involve cleaning up how our `SCMTools` are registered during test runs (we currently register via both fixtures and the management command), and ensuring creation of a `SiteConfiguration` during all test runs. This is a clean-up task for the future. This change also nukes the old baseline evolution schema, which was required back in pre-1.0 to help establish a base set of evolutions and serialized model data so that unwanted changes aren't applied. We don't need this at all anymore, and Django Evolution is smart enough to handle more of those sorts of situations anyway. Removing this simplifies a decent amount of our setup and startup.
    4f4bfea1253bf00b85a519c23425323110eb96be
    chipx86
    chipx86
    david
    1. Ship It!
    2. 
        
    chipx86
    Review request changed
    Status:
    Completed
    Change Summary:
    Pushed to release-4.0.x (423ea5c)