Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
go
go
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 21
    • Issues 21
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • SRCT
  • gogo
  • Issues
  • #134

Closed
Open
Opened Jan 31, 2017 by Mark Stenglein@mstengle

Use sqlite3 on the backend when we know we are using a development environment

Similar to what I am doing for #schedules . This should make it easier to run and do test cases. One really nice feature is that the sqlite library is baked directly into Python. This means that it works on any CI server without a huge amount of extra configuration needed. This issue really looks at creating a development configuration, but sqlite can be configured to just use RAM for a temporary database, which would be ideal for test cases.

Summary

Django doesn't actually care what database you use in the backend. By using sqlite3 in a development environment, it dramatically lightens the complexity of getting a development environment up and running.....like...to the point where using a docker or vagrant container seems silly for development. Why in the world run an entire virtual machine just to get out of having to manually run python manage.py runserver each time you change a file (can you set it to watch filesystem changes?).

The proposed solution below should work as is, but there may be other, more automated ways to switch between environments (perhaps by looking to see if any prod environment vars have been set).

Proposed Solution

In any case, it should be super simple to change: Simply change the relevant area of the settings.py file and also restructure the secret.py a bit:

# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': secret.DB_NAME,
        'USER': secret.DB_USER,
        'PASSWORD': secret.DB_PASSWORD,
        'HOST': secret.DB_HOST,
        'PORT': '',
    }
}

################## CHANGES TO ##################

DATABASES = {
    'default': DATABASE,
}

And for secret.py:

# secret.py

# Use the values from the database configuration
DB_NAME = ""
DB_USER = ""
# Remember to use a strong password in production
DB_PASSWORD = ""
# Often left blank
DB_HOST = ""

################## CHANGES TO ##################

PROD_DB = {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': "",
    'USER': "",
    # Remember to use a strong password in production
    'PASSWORD': "",
    'HOST': "",
    'PORT': '',
}

DEV_DB = {
    'ENGINE': 'django.db.backends.sqlite3',
    'NAME': "goDB.sqlite3",
}

# Change to PROD_DB for production environment
DATABASE = DEV_DB
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: srct/go#134