id = models.AutoField()

Using Django Using the ORM
1

Disclaimer: I am a complete newbie to both Django and database creation is a faint memory from college. So bear with me.

I am using the ‘python manage.py inspectdb > output.py’ command to inspect what errors or items I may need to correct in the class definitions created. I’ve tried searching here and google but I cannot find an answer or example where the primary key is missing in the model, and the id = models.AutoField() is used only once on the first table model with the remainder not showing the pk field as shown below.

For example:

class Alternatives(models.Model):
    id = models.AutoField()
    idealization = models.CharField(max_length=39, blank=True, null=True)
    increase_effectiveness = models.CharField(
                                              db_column='Increase effectiveness', 
                                              max_length=44, blank=True, 
                                              null=True
                                              )

    class Meta:
        managed = False
        db_table = 'alternatives'

The remainder of the tables appear like this even though each table contains a column (id) that is a serial type and not null:

class Primatives(models.Model):
    name = models.CharField(db_column='Name', max_length=128, blank=True, 
                                              null=True)  
    description = models.CharField(max_length=2048, blank=True, null=True)

    class Meta:
        managed = False
        db_table = 'primatives'

Diagram of ‘primatives’ table
postgresqlPrimativeTableERD

I suspect the pk columns may not be listed because they are created as part of the makemigration process normally so the inspectdb function is skipping that part and may require me to copy and paste the id column definition from the ‘Alternatives’ column.

2

Couple different points here:

  • inspectdb is not 100% perfect. See the limitations in the docs for it. It gives you a running start toward integrating an existing database in Django, but it’s not a complete solution. You will still need to evaluate the output before relying upon those models in django.

  • The default behavior for Django Models is to create an auto-incrementing integer primary key with the name “id”. If you do not have a field defined with the attribute primary_key=True, Django will add it to your model automatically.

The inspectdb command does not need to add that to your models, not because it has anything to do with “makemigration”, but because it’s a default within Django itself.
(It exists within the internal class structure of your model - so that when makemigration examines your models, it sees that it exists within the model. This is a subtle difference worth understanding.)

If you have a database table that either has a composite primary_key or doesn’t have a primary_key at all, you’re going to encounter some limitations as to what you can do with that table within Django - particularly in regards to the Django Admin.

If you’re using those tables in a read-only mode, you’ll be ok. You can define just about any field as the primary key, and it will effectively “work”, as long as you never issue a query that relies upon that field being unique if it’s not actually unique. (We’ve had to do that with integrating some legacy data.)
However, in such circumstances, I strongly recommend you make sure that you never try to write to such a table. (We use a custom router to prevent any code from writing to those tables.)

3

I realize both points, especially that ‘inspectdb’ is really just a starting point and have also read the issues with a composite key. (doesn’t work and it’s been an open ticket for the last 15 years)

I guess my question wasn’t properly laid out. The entire dbase is to be read only, I should have mentioned that and that I wanted each primary key defined for each class. That was what I was looking for. A bit more reading says I should use something more like what is below

I see that id = models.AutoField() on the Alternatives class can’t be used (read only db) but instead should perhaps be:

id = models.IntegerField(primary_key=True, blank=False, null=False, unique=True)

Or simply

id = models.IntegerField(primary_key=True)

I’m just shooting in the dark here and appreciate being pointed in the right direction

4

From what you’ve posted so far, I think you are pointed in the right direction. But it actually might be beneficial to describe the general environment and your overall objective.

Is this data from some other system that you’re trying to access?

How does Django fit into this picture? What are you trying to do with it with this database?

If a single-column primary key already exists for the table, you just need to add the primary key attribute to the corresponding column. If a primary key doesn’t exist, and you’re never going to write to that table, you can usually select just about any column to tell Django that it is the primary key - just don’t count on the admin working properly.

Django requires access to a writable database to completely function properly. (You can run Django to some degree without writing to a database, but it takes some planning to avoid the majority of the problems.)
If you’re talking about using a second database as a read-only source, that’s another case for a custom router.

5

I’m aware that I am going to need two or three databases. One static, one for admin/user management and one to build a data model to train an AI with to merge in a later version of the app.

The r/o dbase is built from proven knowledge based methods of innovation and categorized by what problem the end user is trying to resolve and the methods toward the end result. It won’t be updated very often due to the commonalities between patents unless a new discovery (0.006% probability) appears and generates a new set of methods that eventually get published by the community that generates the data.

The r/o database is being put together by scratch by myself, there isn’t any legacy database available to build or transfer the data from.

So you see, I’m a bit of an outlier app wise. I chose Django because it is the most solid and supported Python based framework. I chose Python because the language was the best approach to how I think, the formatting restrictions and the readability of good code. I can’t say the same for C or C++ unless you come across an exceptional programmer of which I’ve only met one who meets that standard.

The cons are, I am having to restart learning Python from scratch having only touched on the periphery of 2.7, roughly 15 years ago. And I have enough knowledge of programming methodology to be considered dangerous by the professional community much the way I viewed programmers with bare knowledge of hardware and OS settings coming from the hardware and systems administration side of the house.

The pros, I can learn from anyone of any age any knowledge that I was not aware of. I can read docs like a screaming demon, and I usually can become a subject matter expert in 3 - 6 months if it is software, administrative or hardware. Last, I’m aware of my limitations. Hence the somewhat obtuse questions I appear to have asked initially. But I’m learning how to clarify better.

But the caveat here is that the field of programming and OOP is something it has taken me years to actually grasp, and it’s always been from the outside. Which as I said, makes me extremely dangerous.

6

In that case, since you’re going to be using this from Django, I’d recommend creating the schema using Django. It’s going to create less friction later on if you’re not trying to manually create it and then hook Django up to it later.

Actually, as Python happens to be the “data science language du jour”, and knowing what we’re doing with Python / Django, you’re probably not as much of an outlier as you might think. I’m constantly meeting people who are using it far outside the general realm of “public facing web pages.”