Code Structure¶

Folders¶

dectech_toolkit: This is the python library developed by the football team for commonly used code. It is used throughout the data tasks to generate the player reports.

fb_api: This folder contains various configurations files for the application. * urls.py - defines the routes of the rest api. * wsgi.py - used as the application entry point for the apache wsgi module. * secrets.json - contains DB, RabbitMQ, Redis and Celery connection details and also token for django and sendgrid. * celery.py - contains the config for the celery and defines when scheduled tasks are to be run. * settings/base_settings.py - contains the django setup details common to all environments. * settings/local.py - contains the django setup details specific to the local env. * settings/development.py - contains the django setup details specific to the local development. * settings/production.py - contains the django setup details specific to the local development.

fb_data: This folder contains the player partial and full report json files.

fb_batch_processes: Contains scripts that process the football match tracking data on multiple EC2s.

fb_overrides: Contains code that overrides any of the core functionality of django. It is used to override django’s builtin reset functionality.

fb_player: Models, tasks, serializers, views specific to just the player reports.

fb_scripts: set of windows and linux scripts of common django commands.

fb_shared: Models, tasks, serializers, views specific common accross all apps.

fb_team: Models, tasks, serializers, views specific to just the team portal.

fb_templates: Contains Dectech Branded email templates used for the password reset flow functionality.

Models¶

The models defined in the models.py in the fb_shared, fb_team and fb_player apps are un managed and therefore don’t work with the django migration tools. Unfortunately the migration tool does not work when an application has models that have relations with other models that span across multiple schemas. Django’s object relational mapper (ORM) cannot not handle this either out of the box.

In order to get the ORM to work cross schema relationship, you have to have define a mysql view in the main django database and then base the model class of that file. Unfortunately this does mean the model is read only.

You can tell a model class is based on a view rather than a table by looking at the class meta data field db_table. A table name without fb_view in the name will be writable and be based on a actual table.

You will be able still use the migration tools for 3rd party and core Django modules.

Changing a Model¶

If you would like to modify a model in Django, you have to manually update the database table both in the dectecho_portal_dev and dectecho_portal_prod schemas.

Step 1

Step 2

Serializers¶

All the serializers defined in the project are based on the Django Rest Framework model serializer class. Serializers allow complex data such as querysets and model instances to be converted to native Python datatypes that can then be easily rendered into JSON, XML or other content types. Serializers also provide deserialization, allowing parsed data to be converted back into complex types, after first validating the incoming data.

More information can be found here: http://www.django-rest-framework.org/api-guide/serializers/

Handling Raw SQL Queries¶

For the player model, a few custom SQL queries are run to retrieve the player’s data such similar players, match history etc. These can be handled by adding get methods to the player model class. The raw custom sql queries can be found fb_player/sqlgenerator.py.

Using the source attribute on the model serializer, you can specify what custom model method to run when the serializer is run.

Views¶

All the view defined in the project are based on the Django Rest Framework view classes that available. These classes provide rest end points rather than the tradional HTML Django templates.

More information can be found here: http://www.django-rest-framework.org/api-guide/views/

Authentication¶

The Rest API uses token based authentication. A user has to login first with username and password to obtain a access token. This token then must be provided in the headers of any secure end point. The token can also be also used to identify the user.

Example Login API Call

Example Get Report API Call

Any view can be protected by adding the relevant permission class to view.

# Returns a specific user's report, only if they have permission to view
class UserReportDetail(APIView):
    permission_classes = (IsAuthenticated,)

More information can be found here: https://django-rest-auth.readthedocs.io