OneToMany relationship in Django with one model locked - django

I know what ForeignKeys and OneToOneFields are, as well as ManyToManyField, how they work, and when to use them. However, I am working with a project, whose Many part of the relation cannot be modified. So, suppose I want to let a user have many phone numbers, I would normally do this:
# my_app/models.py
from django.db import models
class User(Model):
...
class PhoneNumber(models.Model):
user = models.ForeignKey(User)
The problem I have is that my PhoneNumber model equivalent is from a third-party package, already populated with records, and not subclassed in my own app. That is
# third_party_django_package/models.py
from django.db import models
class PhoneNumber(models.Model):
# This cannot change
# my_app/models.py
from django.db import models
from third_party_django_package.models import PhoneNumber
class User(Model):
# These do not work -- a user can have more than one phone number
phone_number = models.ForeignKey(PhoneNumber)
phone_number = models.OneToOneField(PhoneNumber)
# This is close, but I want a phone number to belong to only one User
phone_numbers = models.ManyToManyField(PhoneNumber, related_name=...)
def clean(self):
# Validating the M2M relation costs extra queries, is slow, and
# is prone to race conditions
This is all pseudocode.
Without using yet another third-party package that accesses Django's internal members, which makes the project even less forwards-compatible, what options do I have left to achieve a proper OneToManyField with the correct schema-level constraints?

You could create another intermediate model, then make phone number OneToOneField to that model, then in that model you define User as ForeignKey.
class UserPhoneNumber(models.Model):
phone_number = models.OneToOneField(PhoneNumber)
user = models.ForeignKey(User)
It's a little cumbersome, but at least it achieves what you need.
Edit:
As #Daniel said, it's possible to do this using m2m relationship with through model, with unique_together on the fields:
class User(Model):
phone_numbers = models.ManyToManyField(PhoneNumber, through=UserPhoneNumber)
class UserPhoneNumber(Model):
phone_number = models.ForeignKey(PhoneNumber)
user = models.ForeignKey(User)
class Meta:
unique_together = ('phone_number', 'user')
This will make your life easier if you want to look up on user's phone numbers by doing numbers = user.phone_numbers.all().

Related

Django REST ModelSerializer --- General Question

I am working through a tutorial that includes the building of an articles app. I have an Article model that I am serializing and I am curious about why I need to explicitly set certain fields when using a ModelSerializer.
Here is my model:
from django.db import models
from core.models import TimestampedModel
class Article(TimestampedModel):
slug = models.SlugField(db_index=True, max_length=255, unique=True)
title = models.CharField(db_index=True, max_length=255)
description = models.TextField()
body = models.TextField()
author = models.ForeignKey('profiles.Profile', on_delete=models.CASCADE, related_name='articles')
def __str__(self):
return self.title
Pretty standard stuff. Next step is to serialize the model data in my serializers.py file:
class ArticleSerializer(serializers.ModelSerializer):
author = ProfileSerializer(read_only=True) # Three fields from the Profile app
description = serializers.CharField(required=False)
slug = serializers.SlugField(required=False)
class Meta:
model = Article
fields = (
'author',
'body',
'createdAt',
'description',
'slug',
'title',
'updatedAt',
)
Specifically, why do I need to explicitly state the author, description, and slug fields if I am using serializers.ModelSerializer and pulling those fields in from my model in my class Meta: below?
Thanks!
In the Django-Rest-Framework documentation, drf-docs/model_serializer/specifying-which-fields-to-include it says:
If you only want a subset of the default fields to be used in a model serializer, you can do so using fields or exclude options, just as you would with a ModelForm. It is strongly recommended that you explicitly set all fields that should be serialized using the fields attribute. This will make it less likely to result in unintentionally exposing data when your models change.
Therefore by using fields = in the Serializer META, you can specify just the needed fields, and not returning vital fields like id, or exessive information like updated and created timestamps.
You can also instead of using fields, use exclude, which again takes in a tuple, but just excludes the fields you don't want.
These are especially useful when your database table contains a lot of information, returning all this information, especially if it is listed, can result in large return JSON's, where the frontend may only use a small percentage of the sent data.
DRF has designed their framework like this to specifically combat these problems.
In my opinion, we should define field in serializer for:
Your api use serializer don't need all data of your models. Then you can limit field can get by serializer. It faster if you have so much data.
You dont want public all field of your model. Example like id
Custom field in serializer like serializers.SerializerMethodField() must define in fields for work
Finally, iF you dont want, you can define serializer without define fields. Its will work normally

How do I reuse single model field validators for forms without using ModelForm?

How can I reuse model field validators when creating a form. I can't use ModelForm because the form only uses part of the model's fields and I also have additional form fields.
Minimal example
I have a model for an (encryption) key that is always 32 characters in length and I want to use this restriction in the model and forms that accept that key.
models.py
class EncryptionKey(models.Model)
key = models.CharField("Encryption Key", max_length=32, validators=[validators.MinLengthValidator(32)])
forms.py
class NewUserForm(forms.Form):
first_name = forms.CharField(label='First Name', required=True, max_length=256)
last_name = forms.CharField(label='Last Name', required=True, max_length=256)
key = # How do I reuse the key from the model here?
I am looking for a idiomatic way to do this in Django 2.1.
I spend >20 minutes googling for this but all I find is how to use ModelForm.
Not sure if it is idiomatic or not but you can use fields_for_model helper from django.forms.models:
from django.forms.models import fields_for_model
from yourapp.models import EncryptionKey
class NewUserForm(forms.Form):
first_name = forms.CharField(label='First Name', required=True, max_length=256)
last_name = forms.CharField(label='Last Name', required=True, max_length=256)
key = fields_for_model(EncryptionKey, ['key'])['key']
I am not even sure if that is documented.
I think I found the "canonical" answer in the Django docs for Models (emphasis mine):
Abstract base classes
Abstract base classes are useful when you want to put some common
information into a number of other models. You write your base class
and put abstract=True in the Meta class. This model will then not be
used to create any database table. Instead, when it is used as a base
class for other models, its fields will be added to those of the child
class.
An example:
from django.db import models
class CommonInfo(models.Model):
name = models.CharField(max_length=100)
age = models.PositiveIntegerField()
class Meta:
abstract = True
class Student(CommonInfo):
home_group = models.CharField(max_length=5)
The Student model will have three fields: name, age and home_group.
The CommonInfo model cannot be used as a normal Django model, since it
is an abstract base class. It does not generate a database table or
have a manager, and cannot be instantiated or saved directly.
Fields inherited from abstract base classes can be overridden with
another field or value, or be removed with None.
For many uses, this type of model inheritance will be exactly what you
want. It provides a way to factor out common information at the Python
level, while still only creating one database table per child model at
the database level.
The only downside I can see with this, is that inheritance is used for "has-a" relations and not "is-a". Following the above example: A Student is modelled as being a specialization of common info but obviously isn't.

django orm how to use values and still work with modeltranslation

I am using django v1.10.2
I am trying to create dynamic reports whereby I store fields and conditions and the main orm model information into database.
My code for the generation of the dynamic report is
class_object = class_for_name("app.models", main_model_name)
results = class_object.objects\
.filter(**conditions_dict)\
.values(*display_columns)\
.order_by(*sort_columns)\
[:50]
So main_model_name can be anything.
This works great except that the related models are actually registered with django-modeltranslation and their names do not appear with the right translation field.
So for one of the reports main_model is ProductVariant. ProductVariant hasMany Pattern.
My display columns are :serial_number, created_at, pattern__name
The first two columns are fields that belong to ProductVariant model.
The last one is from Pattern
Pattern model looks like this:
from django.db import models
from django.utils.translation import ugettext_lazy as _
class Pattern(models.Model):
name = models.CharField(_('Pattern Name'), max_length=400)
serial_number = models.CharField(_('Pattern Number'), max_length=100, unique=True)
def __str__(self):
return str(self.name) + ' (' + str(self.serial_number) + ')'
class Meta:
verbose_name = _('Pattern')
verbose_name_plural = _('Patterns')
The queryset calling values() does not return me the expected language zh_hans for the field pattern__name.
I read the documentation about multilingual managers at http://django-modeltranslation.readthedocs.io/en/latest/usage.html#multilingual-manager but I still do not know how to make this work.
Bear in mind that the main_model can be anything depending on what I store in the database.

Django forms with odd model relationship

I am working with an existing database that I can not modify and having some trouble trying to deal with presenting forms for modifying the database in Django. The structure in question is as follows and all models are unmanaged.
class Persons(models.Model):
personid = models.BigIntegerField(primary_key=True, db_column='PersonID')
....
class Phones(models.Model):
phoneid = models.BigIntegerField(primary_key=True, db_column='PhoneID')
number = models.CharField(max_length=60, db_column='Number', blank=True)
type = models.CharField(max_length=15, db_column='Type', blank=True)
...
class Personsphones(models.Model):
personphoneid = models.BigIntegerField(primary_key=True, db_column='PersonPhoneID')
personid = models.ForeignKey(Persons, db_column='PersonID')
phoneid = models.ForeignKey(Phones, db_column='PhoneID')
...
I want to create a form to display all of the 'Phones' associated with a particular 'Persons' and in addition be able to modify/add/remove 'Phones' belonging to a 'Persons'. Right now the only thing I can think of is to display the 'Phones' in a modelformset and then if one is added or removed manually set the 'Personsphones' relation. Any ideas on how to best deal with this model setup?
For making changes to your models you may want to use django-south http://south.aeracode.org/docs/
As far as displaying your 'Phone' under your forms.py you may want to set up class meta like so. With this any changes made to models will reflect on change
class Meta:
model = Persons
exclude = ('user')
In models you may want to use Foreignkey fore relationships between phones and Persons. Better seen in action here https://docs.djangoproject.com/en/dev/ref/models/fields/#foreignkey

how to handle multiple profiles per user?

I'm doing something that doesn't feel very efficient. From my code below, you can probably see that I'm trying to allow for multiple profiles of different types attached to my custom user object (Person). One of those profiles will be considered a default and should have an accessor from the Person class. Storing an is_default field on the profile doesn't seem like it would be the best way to keep track of a default, is it?
from django.db import models
from django.contrib.auth.models import User, UserManager
class Person(User):
public_name = models.CharField(max_length=24, default="Mr. T")
objects = UserManager()
def save(self):
self.set_password(self.password)
super(Person, self).save()
def _getDefaultProfile(self):
def_teacher = self.teacher_set.filter(default=True)
if def_teacher: return def_teacher[0]
def_student = self.student_set.filter(default=True)
if def_student: return def_student[0]
def_parent = self.parent_set.filter(default=True)
if def_parent: return def_parent[0]
return False
profile = property(_getDefaultProfile)
def _getProfiles(self):
# Inefficient use of QuerySet here. Tolerated because the QuerySets should be very small.
profiles = []
if self.teacher_set.count(): profiles.append(list(self.teacher_set.all()))
if self.student_set.count(): profiles.append(list(self.student_set.all()))
if self.parent_set.count(): profiles.append(list(self.parent_set.all()))
return profiles
profiles = property(_getProfiles)
class BaseProfile(models.Model):
person = models.ForeignKey(Person)
is_default = models.BooleanField(default=False)
class Meta:
abstract = True
class Teacher(BaseProfile):
user_type = models.CharField(max_length=7, default="teacher")
class Student(BaseProfile):
user_type = models.CharField(max_length=7, default="student")
class Parent(BaseProfile):
user_type = models.CharField(max_length=7, default="parent")
First of all you could make things a lot more easy by not declaring the BaseProfile abstract:
from django.db import models
from django.contrib.auth.models import User, UserManager
class Person(User):
public_name = models.CharField(max_length=24, default="Mr. T")
objects = UserManager()
def save(self):
self.set_password(self.password)
super(Person, self).save()
def _getDefaultProfile(self):
try:
return self.baseprofile_set.get(default=True)
except ObjectDoesNotExist:
return False
profile = property(_getDefaultProfile)
def _getProfiles(self):
return self.baseprofile_set.all()
profiles = property(_getProfiles)
class BaseProfile(models.Model):
person = models.ForeignKey(Person)
is_default = models.BooleanField(default=False)
class Teacher(BaseProfile):
user_type = models.CharField(max_length=7, default="teacher")
class Student(BaseProfile):
user_type = models.CharField(max_length=7, default="student")
class Parent(BaseProfile):
user_type = models.CharField(max_length=7, default="parent")
The way this is nicer? Your properties didn't know anyway what type they were returning, so the abstract baseclass only made you have an incredible annoying overhead there.
If you now are wondering how the hell you can get the data from the specific profiles since I made anything returned BaseProfile? You can do something like this:
try:
#note the lowercase teacher referal
print myuser.profile.teacher.someteacherfield
except Teacher.DoesNotExist:
print "this is not a teacher object!"
Also I do hope you didn't use the user_type field solely for this purpose, because django has it built in better as you can see. I also hope you really have some other unique fields in your derived profile classes because otherwise you should throw them away and just past a usertype field into BaseProfile (look at choices to do this good).
Now as for the is_default, imho this method is as good as any. You can always try to add custom constraints to your dbms itself, saying there sould be 0 or 1 records containing the same FK and is_default=True (there is no django way to do this). What I also would say is, add a method make_default and in that method make sure the is_default is unique for that person (e.g. by first setting is_default to False on all profiles with the same FK). This will save you a lot of possible sorrow. You can also add this check in the save() method of BaseProfile.
Another way you could do it is by adding a Foreign Key to the Person Model that points to the default Profile. While this will ensure default to be unique on django level, it can also provide denormalization and corruption of your data, even on a more annoying level, so I'm no big fan of it. But again, if you do all adding/removing/updating of profiles through predefined methods (will be more complex now!) you should be safe.
Finally, maybe you have good reasons to inherit from User, but the default way to extend the User functionality is not this, it's described here.