Skip to content
Provides the data models for the collection of startup accelerator application initiated by MassChallenge.
Python Other
  1. Python 98.9%
  2. Other 1.1%
Branch: development
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


License: MIT Build Status Test Coverage Maintainability

  1. Overview
  2. Quickstart
    1. As a dependency for MassChallenge's Accelerate/Impact-API
    2. As a dependency for a stand-alone django project
  3. Development
    1. Changing A Swappable Model
    2. Generating Migrations
    3. Running Migrations
    4. Testing

Accelerator is a simple Django package which provides models for the MassChallenge Accelerator applications.


The package supports two modes of use, in two different Django apps:

  • accelerator_abstract - abstract models, declaring all the fields and relationships between the Base-models. All the models were made to be swappable,using Django-swappable-models.
  • accelerator - regular concrete django models, ready for use. Those models are the default concrete implementation of the abstract models defined in accelerator_abstract.

The package also includes a third django app, simpleuser, that slightly extends the default django user model. It is also swappable, in the usual way.


As a dependency for MassChallenge's Accelerate/Impact-API

The development environment for Accelerate and Impact-API were configured to use django-accelerator as an editable source.

Follow the instructions on Setting Up The Development Environment for further details.

As a dependency for a stand-alone django project

  1. Add "accelerator" to your INSTALLED_APPS setting like this:


2. Run python migrate

3. The installed models should now appear in your application's admin and through the Django shell.


Changing A Swappable Model

Since Django-accelerator uses Swappable Models. changing the Django models is slightly different than usual.

The key differences to note are:

  • All the model declarations - Django fields, methods, meta configration, etc. - should live in the respective Base model, inside accelerator_abstract.models. This makes the changes usable both by the accelerator app, and any app that inherits directly from accelerator_abstract and declares its own concrete models.

  • The Concrete model in accelerator should have no other role but:

    • to be a concrete subclass of a base model.
    • to declare the Meta.swappable configuration.

    E.g. the Startup model looks like this:

    # accelerator/models/
    import swapper
    from accelerator_abstract.models import BaseStartup
    class Startup(BaseStartup):
       class Meta(BaseStartup.Meta):
           swappable = swapper.swappable_setting(BaseStartup.Meta.app_label,
  • Model relationships are declared in such a way that allows them to be swappable. E.g:

    # accelerator_abstract/models/
      primary_industry = models.ForeignKey(
          swapper.get_model_name(AcceleratorModel.Meta.app_label, 'Industry'),  
  • Whenever using models that are expected to be swapped, you should use dynamic imports in a similar fashion. Any code that lives inside accelerator_abstract falls under this category.


    # accelerator_abstract/
    import swapper
    BaseProfile = swapper.load_model(, 'BaseProfile')
  • accelerator.tests.factories module contains all the Factory-Boy classes for the django-accelerator models. They must be defined in the concrete app, since the factories need a concrete class to work with. But in order for the factories to be swappable as well, they also use dynamic imports:

    # accelerator/tests/factories/
    import swapper
    Currency = swapper.load_model(, 'Currency')
    class CurrencyFactory(DjangoModelFactory):
      class Meta:
          model = Currency

    So instead of importing Currency directly, it is imported dynamically. This allowes us to use the same factory class for custom models (as long as the custom model doesn't change the abstract fields, but only changes methods or Meta configrurations).

  • Migrations can be made swappable as well, but they are not generated correctly by Django, and require slighlty changing the auto-generated migration, according to the instructions in Django-swappable-models. This feature is not promised to be supported in this repo.

Generating Migrations

Running make migrations will try to generate new migrations for accelerator and simpleuser apps.

Running Migrations

As this is a package and not a full app, it is impossible to run stand-alone migrations. The Makefile is configured to run the migrations in the impact-api project in which this project is installed.


To test this locally, it is possible to run make tox.

Also, Running make test will simply run the tests under the makefile's default Python+Django versions.

Copyright 2019, MassChallenge, Inc., some rights reserved Public license: MIT

You can’t perform that action at this time.