October 17, 2017 at 4:31 pm
Does anyone have any experience with django and how it works with databases in development?
I am getting thrown in to an environment where the developer is using django with SQL Server 2012 (originally PostgreSQL). I need to figure out a way to put the database under source control without impacting the developer (much).
October 19, 2017 at 7:16 am
Sure. I've used Django with SQL Server, but have mostly switched to using Flask over Django in the past year.
Django essentially has a settings file to define what database you will be working with. Here is likely the example your d
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',
'NAME': 'mydatabase',
'USER': 'mydatabaseuser',
'PASSWORD': 'mypassword',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
I don't believe Django supports MSSQL out the box, at least not when I used it. In Python, we all pretty much use a module like PyODBC. Django has their own version called django_pyodbc which is also a separate installation if he/she has not installed already. Then you add it just like the example above:
DATABASES = {
'default': {
'ENGINE': 'django_pyodbc',
'NAME': 'mydatabase',
'USER': 'mydatabaseuser',
'PASSWORD': 'mypassword',
'HOST': '127.0.0.1',
'PORT': '1433',
}
}
So, that's the connection bit. When it comes to creating the data models. It's all ORM at this point. Anytime the developer includes the Django DB package, it's essentially arming them with everything they need to create tables, pre-generated queries (which you will hate), raw queries, keys, and the works. Here is an example of how easy it is for the developer to create a data model from the class models they define for use in the app:
from django.db import models
class Musician(models.Model):
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
instrument = models.CharField(max_length=100)
class Album(models.Model):
artist = models.ForeignKey(Musician, on_delete=models.CASCADE)
name = models.CharField(max_length=100)
release_date = models.DateField()
num_stars = models.IntegerField()
This essentially defines he/she needs two tables with these columns set at the data type and lengths within each field. When this is executed, Django will spit out all the SQL needed to create the tables, data types, lengths, keys and relationships if defined within MSSQL.
With that said, I just kind of wanted to give you an idea of how the developer can define and easily change the models and queries. In terms of source control, all it takes if for them to add one line of code to the end of the code above to add a new field without your knowledge. The best option for you is likely just going to be good communication with the developers to understand when things change and how you can push those changes from your end into source control. Other than that, the Python code is in source control and technically, all the data models and so forth are saved there too.
October 19, 2017 at 8:36 am
xsevensinzx - Thursday, October 19, 2017 7:16 AMSure. I've used Django with SQL Server, but have mostly switched to using Flask over Django in the past year.Django essentially has a settings file to define what database you will be working with. Here is likely the example your d
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',
'NAME': 'mydatabase',
'USER': 'mydatabaseuser',
'PASSWORD': 'mypassword',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}I don't believe Django supports MSSQL out the box, at least not when I used it. In Python, we all pretty much use a module like PyODBC. Django has their own version called django_pyodbc which is also a separate installation if he/she has not installed already. Then you add it just like the example above:
DATABASES = {
'default': {
'ENGINE': 'django_pyodbc',
'NAME': 'mydatabase',
'USER': 'mydatabaseuser',
'PASSWORD': 'mypassword',
'HOST': '127.0.0.1',
'PORT': '1433',
}
}So, that's the connection bit. When it comes to creating the data models. It's all ORM at this point. Anytime the developer includes the Django DB package, it's essentially arming them with everything they need to create tables, pre-generated queries (which you will hate), raw queries, keys, and the works. Here is an example of how easy it is for the developer to create a data model from the class models they define for use in the app:
from django.db import modelsclass Musician(models.Model):
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
instrument = models.CharField(max_length=100)class Album(models.Model):
artist = models.ForeignKey(Musician, on_delete=models.CASCADE)
name = models.CharField(max_length=100)
release_date = models.DateField()
num_stars = models.IntegerField()This essentially defines he/she needs two tables with these columns set at the data type and lengths within each field. When this is executed, Django will spit out all the SQL needed to create the tables, data types, lengths, keys and relationships if defined within MSSQL.
With that said, I just kind of wanted to give you an idea of how the developer can define and easily change the models and queries. In terms of source control, all it takes if for them to add one line of code to the end of the code above to add a new field without your knowledge. The best option for you is likely just going to be good communication with the developers to understand when things change and how you can push those changes from your end into source control. Other than that, the Python code is in source control and technically, all the data models and so forth are saved there too.
Perfect... I just absolutely love it when sensitive credentials are stored in a file in clear text.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 19, 2017 at 9:29 am
Yep, unfortunately, that's the way it goes most of the time with these types of apps. I mean, if the source code itself is compromised without the password, you can see how easily it is to make your own table and insert your own users and so forth without that password. You can dramatically change the entire database with Python code extremely easy.
You can store the credentials in a separate file that is completely locked down to specific users as well encrypted. Where the script itself can import those credentials if executed under a specific user each time. Another way may be adding a service between the script and the database where that middle service has the credentials and the script is just authenticating with that service (oAuth) to make those calls. That way if the script is compromised, the actual user and information of the database is not. You can even force the authentication to invalidate itself too (i.e.: force the authentication token) on top of expire after X days.
October 19, 2017 at 9:48 am
I should also mention, you can force the developer to only use stored procedures you create. This will help you keep a lock on how they are interacting with the database as opposed to allowing Django to generate that SQL the best way it knows how. Nothing wrong with that in this aspect outside most developers do dislike the wait time of having that SP created before they can move forward. The same can apply to the core models as well. The purpose of the ORM is to put the power in their hands as they develop. This is essentially the main debate between using this over just having a DBA do it for you the right way.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply