20👍
A work around is to create a surrogate key (an auto increment column) as the primary key column and place a unique index on your domain composite key.
Foreign keys will then refer to the surrogate primary key column.
24👍
Why not add a normal primary key, and then specify that part_number and part_revision as unique_together?
This essentially is the Djangoish (Djangonic?) way of doing what Mitch Wheat said.
- Django: dynamic database file
- Make Django return response as a "different filename"
- Django error: [<class 'decimal.InvalidOperation'>]
- In django, is aggregate(Count()) faster or better than .count() in anyway?
14👍
I strongly suggest using a surrogate key. Not because it is “Djangoesque”. Suppose that you use a composite key that includes part_number. What if some time later your company decides to change the format (and therefore values) of that field? Or in general terms, any field? You would not want to deal with changing primary keys. I don’t know whatever benefit you see in using a composite key that consists of “real” values, but I reckon it isn’t worth the hassle. Use meaningless, autoincremented keys (and that should probably render a composite key useless).
- What is the opposite of @login_required decorator for Django views?
- Best way to reference the User model in Django >= 1.5
- Python 2 -> 3 Django migration causes field parameter type change
- Django Rest Framework – Create foreign key object on POST
- How to specify name in Django mail?
2👍
SQLAlchemy has support for composite primary and foreign keys, so any SQLAlchemy based framework (Pylons and Werkzeug comes to mind) should suite your needs. But surrogate primary key is easier to use and better supported anyway.
- Django – Check diference between old and new value when overriding save method
- What permissions does django-storages require for an s3 IAM user?
- Django model subclassing approaches