I've read a few places (see the second answer) that one-to-one relationships in Django models should almost always only be used for inheritance, or to access an otherwise inaccessible model (like the Django user model).
However, it seems like there are cases where you have an object that will always have exactly one instance of another object where you would logically want to separate those two objects. Say, for example, your app was storing information about cars. Each car has exactly one driver and each driver only drives one car. Does it not make sense to separate car and driver into two separate models?
Imagine you have a company and make intranet tool listing all employees, their positions, offices, departments, salaries, etc. You would make in Django models.py a class Employee, maybe something like this:
class Employee(models.Model):
first_name = models.CharField(max_length=255)
last_name = models.CharField(max_length=255)
position = models.CharField(max_length=255)
office = models.CharField(max_length=20)
salary = models.IntegerField()
department = models.ForeignKey(Department, related_name='employees')
But for some reasons you don't want the salary to be accessible to all employees, maybe there are many people with redactor status in the admin area, and decide to outsource it to its own model and change the model Employee:
class Employee(models.Model):
# above attributes
salary = models.OneToOneField(Salary)
There are certainly other ways to hide this information, but one possibility is to divide the information in two tables even though it is just plain 1:1 relation.
Your company is a software company and you introduce pair programming. Every employee has a pair programming partner. It can be just one programming partner. So you adapt your model again:
class Employee(models.Model):
# above attributes
pair_programmer = models.OneToOneField('self')
This would be a recursive one-to-one relation.
One-to-one relations are not very common and hard to find in beginners' tutorials, but if there are some specific requirements, you find yourself creating 1:1 relation for solving the problem.
Here is a real life example from my work. I'm bioinformatician and make software for microorganisms. They are classed in genera and species. Every genus may contain one or more species, but a species can belong to only one genus. That is a clear 1:n relation. But now, a genus has a type species, only one and just one. And the type species can belong to one genus. Here I put models.OneToOneField, besides the models.ForeignKey.
Don't worry a lot about 1:1 relations in advance. When you come to some specific problem, then you'll figure out if you need 1:1 relation.
The django documentation gives a great answer:
For example, if you were building a database of “places”, you would
build pretty standard stuff such as address, phone number, etc. in the
database. Then, if you wanted to build a database of restaurants on
top of the places, instead of repeating yourself and replicating those
fields in the Restaurant model, you could make Restaurant have a
OneToOneField to Place (because a restaurant “is a” place; in fact, to
handle this you’d typically use inherit Each car has exactly one driver and each driver only drives one car. Does it not make sense to separate car anance, which involves an
implicit one-to-one relation).
Django uses OneToOne to model inheritance (and might use it internally, I haven't checked out the source though). I feel like if there is a tool django is providing and you can use that tool in a way that you can defend, why not use it? It seems like it makes sense, that if a car only has one driver, then enforce that in the db using the tools (OneToOneField) that django provides
Related
This is more of a conceptual/engineering question than an actual programming question, but I keep going back and forth between what is the "right" thing to do here. For quick background, I am still a bit of a noob at python/django and don't have a ton of experience working with classes.
The program I'm trying to develop is an inventory management app.
There are multiple products but lets simplify and say one is shoes and one is clothing. Both products share some attributes (UPC, size, color, etc), but also have some unique attributes (shoe_width, clothing_type) as well.
Additionally, it seems like I should have a separate Product class (unique product attributes UPC, size shoe_width, clothing_type) and InventoryItem class (attributes unique to each piece of inventory such as price paid or condition) that inherits its corresponding Product class attributes.
EDIT2: clothing_type is unique to clothing, but shoe_width should be unique to the actual shoe InventoryItem and not the shoe Product. This sort of complicates the question, as now I'm thinking I'll need not only seperate Clothing and Shoe classes, but also ClothingInventoryItem & ShoeInventoryItem classes to deal with unique fields down at the inventory level.
Conceptually, I am trying to build this multi-purpose. Users should be able to view product information (not inventory related) and add products and inventory items via django admin or via spreeadsheet upload (spreadsheet hooks already built.)
So to the actual question, what is the correct way to implement the individual classes and what are some of the problems I may run into or drawbacks to doing so? I'm having a problem visualizing how this would work.
Should I:
A)
Have a ProductType field (make two initial entries of "Shoe" &
"Clothing")
Have separate "Shoe" and "Clothing" classes which inherit ProductType
via models.ForeignKey(ProductType). They would then have their own
unique fields regardless if they share some fields.
Have an InventoryItem class that then inherits Shoe or Clothing via ForeignKey.
The only limitation I can see is that the admin users would not be able to add new ProductType without me having to write a new class for that new ProductType (which is totally fine.)
Thanks in advance.
Edit: When I was initially typing this, the alternative scenario would be to do these relationships correctly via python nested classes and then feed the info into the django model classes...but this seems redundant and unnecessary.
tl;dr
Is there a simple alternative to multi-table inheritance for implementing the basic data-model pattern depicted below, in Django?
Premise
Please consider the very basic data-model pattern in the image below, based on e.g. Hay, 1996.
Simply put: Organizations and Persons are Parties, and all Parties have Addresses. A similar pattern may apply to many other situations.
The important point here is that the Address has an explicit relation with Party, rather than explicit relations with the individual sub-models Organization and Person.
Note that each sub-model introduces additional fields (not depicted here, but see code example below).
This specific example has several obvious shortcomings, but that is beside the point. For the sake of this discussion, suppose the pattern perfectly describes what we wish to achieve, so the only question that remains is how to implement the pattern in Django.
Implementation
The most obvious implementation, I believe, would use multi-table-inheritance:
class Party(models.Model):
""" Note this is a concrete model, not an abstract one. """
name = models.CharField(max_length=20)
class Organization(Party):
"""
Note that a one-to-one relation 'party_ptr' is automatically added,
and this is used as the primary key (the actual table has no 'id'
column). The same holds for Person.
"""
type = models.CharField(max_length=20)
class Person(Party):
favorite_color = models.CharField(max_length=20)
class Address(models.Model):
"""
Note that, because Party is a concrete model, rather than an abstract
one, we can reference it directly in a foreign key.
Since the Person and Organization models have one-to-one relations
with Party which act as primary key, we can conveniently create
Address objects setting either party=party_instance,
party=organization_instance, or party=person_instance.
"""
party = models.ForeignKey(to=Party, on_delete=models.CASCADE)
This seems to match the pattern perfectly. It almost makes me believe this is what multi-table-inheritance was intended for in the first place.
However, multi-table-inheritance appears to be frowned upon, especially from a performance point-of-view, although it depends on the application. Especially this scary, but ancient, post from one of Django's creators is quite discouraging:
In nearly every case, abstract inheritance is a better approach for the long term. I’ve seen more than few sites crushed under the load introduced by concrete inheritance, so I’d strongly suggest that Django users approach any use of concrete inheritance with a large dose of skepticism.
Despite this scary warning, I guess the main point in that post is the following observation regarding multi-table inheritance:
These joins tend to be "hidden" — they’re created automatically — and mean that what look like simple queries often aren’t.
Disambiguation: The above post refers to Django's "multi-table inheritance" as "concrete inheritance", which should not be confused with Concrete Table Inheritance on the database level. The latter actually corresponds better with Django's notion of inheritance using abstract base classes.
I guess this SO question nicely illustrates the "hidden joins" issue.
Alternatives
Abstract inheritance does not seem like a viable alternative to me, because we cannot set a foreign key to an abstract model, which makes sense, because it has no table. I guess this implies that we would need a foreign key for every "child" model plus some extra logic to simulate this.
Proxy inheritance does not seem like an option either, as the sub-models each introduce extra fields. EDIT: On second thought, proxy models could be an option if we use Single Table Inheritance on the database level, i.e. use a single table that includes all the fields from Party, Organization and Person.
GenericForeignKey relations may be an option in some specific cases, but to me they are the stuff of nightmares.
As another alternative, it is often suggested to use explicit one-to-one relations (eoto for short, here) instead of multi-table-inheritance (so Party, Person and Organization would all just be subclasses of models.Model).
Both approaches, multi-table-inheritance (mti) and explicit one-to-one relations (eoto), result in three database tables. So, depending on the type of query, of course, some form of JOIN is often inevitable when retrieving data.
By inspecting the resulting tables in the database, it becomes clear that the only difference between the mti and eoto approaches, on the database level, is that an eoto Person table has an id column as primary-key, and a separate foreign-key column to Party.id, whereas an mti Person table has no separate id column, but instead uses the foreign-key to Party.id as its primary-key.
Question(s)
I don't think the behavior from the example (especially the single direct relation to the parent) can be achieved with abstract inheritance, can it? If it can, then how would you achieve that?
Is an explicit one-to-one relation really that much better than multi-table-inheritance, except for the fact that it forces us to make our queries more explicit? To me the convenience and clarity of the multi-table approach outweighs the explicitness argument.
Note that this SO question is very similar, but does not quite answer my questions. Moreover, the latest answer there is almost nine years old now, and Django has changed a lot since.
[1]: Hay 1996, Data Model Patterns
While awaiting a better one, here's my attempt at an answer.
As suggested by Kevin Christopher Henry in the comments above, it makes sense to approach the problem from the database side. As my experience with database design is limited, I have to rely on others for this part.
Please correct me if I'm wrong at any point.
Data-model vs (Object-Oriented) Application vs (Relational) Database
A lot can be said about the object/relational mismatch,
or, more accurately, the data-model/object/relational mismatch.
In the present
context I guess it is important to note that a direct translation between data-model,
object-oriented implementation (Django), and relational database implementation, is not always
possible or even desirable. A nice three-way Venn-diagram could probably illustrate this.
Data-model level
To me, a data-model as illustrated in the original post represents an attempt to capture the essence of a real world information system. It should be sufficiently detailed and flexible to enable us to reach our goal. It does not prescribe implementation details, but may limit our options nonetheless.
In this case, the inheritance poses a challenge mostly on the database implementation level.
Relational database level
Some SO answers dealing with database implementations of (single) inheritance are:
How can you represent inheritance in a database?
How do you effectively model inheritance in a database?
Techniques for database inheritance?
These all more or less follow the patterns described in Martin Fowler's book
Patterns of Application Architecture.
Until a better answer comes along, I am inclined to trust these views.
The inheritance section in chapter 3 (2011 edition) sums it up nicely:
For any inheritance structure there are basically three options.
You can have one table for all the classes in the hierarchy: Single Table Inheritance (278) ...;
one table for each concrete class: Concrete Table Inheritance (293) ...;
or one table per class in the hierarchy: Class Table Inheritance (285) ...
and
The trade-offs are all between duplication of data structure and speed of access. ...
There's no clearcut winner here. ... My first choice tends to be Single Table Inheritance ...
A summary of patterns from the book is found on martinfowler.com.
Application level
Django's object-relational mapping (ORM) API
allows us to implement these three approaches, although the mapping is not
strictly one-to-one.
The Django Model inheritance docs
distinguish three "styles of inheritance", based on the type of model class used (concrete, abstract, proxy):
abstract parent with concrete children (abstract base classes):
The parent class has no database table. Instead each child class has its own database
table with its own fields and duplicates of the parent fields.
This sounds a lot like Concrete Table Inheritance in the database.
concrete parent with concrete children (multi-table inheritance):
The parent class has a database table with its own fields, and each child class
has its own table with its own fields and a foreign-key (as primary-key) to the
parent table.
This looks like Class Table Inheritance in the database.
concrete parent with proxy children (proxy models):
The parent class has a database table, but the children do not.
Instead, the child classes interact directly with the parent table.
Now, if we add all the fields from the children (as defined in our data-model)
to the parent class, this could be interpreted as an implementation of
Single Table Inheritance.
The proxy models provide a convenient way of dealing with the application side of
the single large database table.
Conclusion
It seems to me that, for the present example, the combination of Single Table Inheritance with Django's proxy models may be a good solution that does not have the disadvantages of "hidden" joins.
Applied to the example from the original post, it would look something like this:
class Party(models.Model):
""" All the fields from the hierarchy are on this class """
name = models.CharField(max_length=20)
type = models.CharField(max_length=20)
favorite_color = models.CharField(max_length=20)
class Organization(Party):
class Meta:
""" A proxy has no database table (it uses the parent's table) """
proxy = True
def __str__(self):
""" We can do subclass-specific stuff on the proxies """
return '{} is a {}'.format(self.name, self.type)
class Person(Party):
class Meta:
proxy = True
def __str__(self):
return '{} likes {}'.format(self.name, self.favorite_color)
class Address(models.Model):
"""
As required, we can link to Party, but we can set the field using
either party=person_instance, party=organization_instance,
or party=party_instance
"""
party = models.ForeignKey(to=Party, on_delete=models.CASCADE)
One caveat, from the Django proxy-model documentation:
There is no way to have Django return, say, a MyPerson object whenever you query for Person objects. A queryset for Person objects will return those types of objects.
A potential workaround is presented here.
We are developing a collection management project using Django, usable for different types of collections.
This problem quite naturally divides itself in two:
The common part, that will be shared by all collections.
The specializations, different for each collection type.
Example
To illustrate this a bit further, let's take a simplified example in pseudocode.
Common part
class ItemBase: # ideally abstract
name = CharField()
class Rental
item = ForeignKey("Item")
rented_to_person = CharField()
Specialization for a collection of cars
class ItemSpecialization
horse_power = Int()
The problem
The question is how we could organize the code in order to allow reuse of the common part without duplicating its content ?
We would imagine it would be best to have the common part as a non-installed application, and have each specialized configuration as a separate installed application. But this would cause a problem with the Rental concrete class, because it resides in the common-part application.
Any advices on how we could proceed ?
It really depends on what you want, you may use an abstract model class for common stuff, and inherit from that in specialized model classes.
Otherwise, if you really want one table for all common data, typically to be able to relate to it, then you'll need your specialized model to have a relation to the common model. It can be a foreign key, or you can use model inheritance, in which case the foreign key in question will be managed for you by django, but it'll be harder to use.
It sounds like you're looking for a OneToOneField field relationship. Based on your example:
class ItemBase:
name = models.CharField(max_length=50)
class Rental:
item = models.OneToOneField(ItemBase)
rented_to_person = models.CharField(max_length=50)
class ItemSpecialization
item = models.OneToOneField(ItemBase)
horse_power = models.IntegerField()
With this model hierarchy, you could fetch Rental or ItemSpecialzation objects and also gain access to ItemBase fields. It's basically OO inheritance for Django models. More details in the docs: https://docs.djangoproject.com/en/1.9/topics/db/examples/one_to_one/
I am building a website for selling bikes in django. I have a class Bike that will contain the bikes; it looks like this :
class Bike(models.Model):
brand = models.CharField(max_length=100)
model = models.CharField(max_length=100)
Now I would like to add a field wheels describing the wheels of the bike, and I would like this field to contain possibly several fields like the brand, size of the wheel. I would like these details on wheels implementation to be separated from the bike's class specification; however, I expect each wheel to be associated to exactly one bike.
An idea I had was to do the following :
class Wheels(models.Model):
description = models.CharField(max_length=100)
size = models.DecimalField(max_digits=5,decimal_places=2)
and then to include a new field in my bike :
class Bike(models.Model):
# previous fields
wheels = models.ForeignKey(Wheels)
I have however some doubts about it :
1) is it the correct design ? If I do that I will end up with a wheels' database which I don't think I actually need. I just want to have flexible fields in my bike database.
Basically I expect that I will have a one to one relationship between bikes and wheels.
2) If this is the correct design, then what I would like is to be able to add wheels on the fly while adding bike (never have to add wheels separately). What is the best way to do that ?
Thanks a lot for any hint / reference. I am a beginner with django...
I doubt that (in real life) you really will have a one-to-one relationship between bike and wheels - more than one bike model will surely use the same wheels.
Similar real life relationships exist between bike brands/models and components such as derailleurs, brakes, cranks, pedals etc.
By the way, you would not have separate databases for each component, each component would be modelled as a table within the same database.
So my advice is to go with the multiple table approach because you will eventually have the same components used on different bikes, and possibly vice versa for cases where there are optional components within the same basic bike model, e.g. same bike but different wheel sizes.
That design looks good to me - it's a good idea to keep individual objects in separate tables (in this case the components that make up the bike - particularly since they can be sold separately, and bikes can be customised with different parts)
I think a simple preset class inherited from the Bicycle class should do the trick:
class BicycleFrame(models.Model):
brand = models.ForeignKey(Brand)
model = models.CharField(max_length=100)
# class BicycleWheels, BicyclePedals etc..
class Bicycle(models.Model):
frame = models.ForeignKey(BicycleFrame)
wheels = models.ForeignKey(BicycleWheels)
pedals = models.ForeignKey(BicyclePedals)
# etc ...
class PresetBicycle(Bicycle):
pass
class PurchaseableMixin(models.Model):
user_id = models.ForeignKey(Customer)
def purchase(self):
# ... call this in the form handler to save this
# instance of a bike in the database and maybe
# email the customer to inform them of their purchase etc..
class Meta:
abstract = True
class PurchasedBicycle(Bicycle, PurchaseableMixin):
pass
.. then you can create a PresetBicycle in your admin area then in the view that you show to customers you could display the PresetBicycle by default and also provide a form to purchase it that is auto filled with the details for the PresetBicycle and that creates an instance of a PurchasedBicycle on submission (a JS framework like ReactJS and Backbone, or Angular might be best for the customer view).
Hope this helps!
P.S. Note that I haven't tested this approach myself - I'd suggest creating a few new branches in your Version Control (eg git) and setting up separate settings files for each one (import from a base settings file and use a separate database for each one to save having to mess around with too many migrations and obsolete tables) to test several approaches before making your final decision - it's good to figure this stuff out early on so that you don't end up making big structural changes later on.
P.P.S Also not that I've changed the brand field to be a ForeignKey, since you may later wish to filter on the brand..
i am new to both python and Django, trying to create a database that hold general information about people, so i have this:
a model for a Person (contain general info).
a model for a Category that a person belongs to (a person can be in multiple categories at the same time).
each category contain its own extra data (a person who is in "Writers" category might have some books that we want to store in DB)
i thought about model sub-classing, but it seems that this will not work if a person can be in multiple categories the same time (especially dynamically)
another thought is creating profiles that have OneToOne relationship with the Person model, but i am not sure if it is the best way
what is the best/other ways to tackle this?
It sounds like you want each category to have a ForeignKey to Person.
add ManyToManyField(Category) to Person class.
Django permissions in User model are solved the same way (via Group class)
edit:
you're right, I'm sorry about my useless answer.
My solution would looks like this:
Class Person(Model):
#property
def extras(self):
extra_data = {}
for category in self.categories.all():
category_model_class = CATEGORIES_DATA_MAP[category.name]
extra_data[category.name] = category_model_class.objects.filter(user=self.pk)
return extra_data
... where CATEGORIES_DATA_MAP is dictionary with category/model relation map
The multiple 1to1 rel is the way to go.
Define an ActorProfile model, a WriterProfile model etc, with each having a fk to User. Use some orm magic to load then when necessary.
It's basic that the FK is in the profile model, otherwise you'll need to add a new column on the user table each time you need a new kind of profile.
As the profiles will be probably somewhat overlapping, I'd suggest to use composition (instead of inheritance), do more profile types which store the common data, and keep the specific profiles for very specific data.
EDIT
Use a document-based database (mongodb?) and forget about migrations, fixed schemata, artificial joins... You have to think only about structuring the data the way you really need, but the advantages are worth considering.