I am having the following model class hierarchy:
from django.db import models
class Entity(models.Model):
createTS = models.DateTimeField(auto_now=False, auto_now_add=True)
class Meta:
abstract = True
class Car(Entity):
pass
class Meta:
abstract = True
class Boat(Entity):
pass
class Amphibious(Boat,Car):
pass
Unfortunately, this does not work with Django:
shop.Amphibious.createTS: (models.E006) The field 'createTS' clashes with the field 'createTS' from model 'shop.boat'.
Even if I declare Boat abstract, it doesn't help:
shop.Amphibious.createTS: (models.E006) The field 'createTS' clashes with the field 'createTS' from model 'shop.amphibious'.
Is it possible to have a model class hierarchy with multiple inheritance and a common base class (models.Model subclass) that declares some fields?
Use this and see if it helps. If you are trying to include the timestamp to the models then just create a base model which includes only the timestamp.
from django.db import models
class Base(models.Model):
created = models.DateTimeField(auto_now_add=True)
updated = models.DateTimeField(auto_now=True)
class Meta:
abstract = True
class Boat(Base):
boat_fields_here = models.OnlyBoatFields()
class Amphibious(Boat):
# The boat fields will already be added so now just add
# the car fields and that will make this model Amphibious
car_fields_here = models.OnlyCarFields()
I hope this helps. I see that it has been 5 months since you posted this question. If you have already found a better solution then please share it with us, will help us a lot for learning. :)
Related
I have been using django and used class Meta: a lot of times, actually what is the use of it?
for example , In django models
class Accounts(models.Model):
---some code here---
class Meta:
ordering = [-1]
In django forms
class AccountForm(forms.ModelForm):
---some code here---
class Meta:
fields = '__all__'
class Meta is basically the inner class. In Django, the use of the Meta class is simply to provide metadata to the ModelForm or the Model class. It is different from the metaclass of a Class in Python.
class Meta is used to change the behavior of the models such ordering, verbose_name etc. Though it is optional to be included in your models.
I am using Django 2.0.8 and Python 3.5 for a project. I have different models in my project, some of which, I want to allow commenting on - with both the object (e.g. a blogpost) and comments to the blogpost being likeable.
I am using the threaded comments django app to provide commenting functionality.
Assuming I have a model Foo (see below):
from django.db import models
from django.conf import settings
class Foo(models.Model):
owner = models.ForeignKey(settings.AUTH_USER_MODEL, blank=False, null=False, default=1, on_delete = models.PROTECT)
# ...
class Likeable():
pass
class Rateable():
pass
How could I use mixins (or any other mechanism for that matter), to make the object Foo "commentable" (i.e. an object which can be commented upon), "likeable" (i.e. an object which can be commented upon) and "rateable" (i.e. an object which can be rated?)- bearing in mind that comments on an objects may be BOTH liked and rated.
According to django documentation , you can achieve this using the Content types Framework. ContentType is a generic model that permits you to track all the models included in INSTALLED_APPS using for that their app_label, model_name and pk. The way it works is easy:
Your generic Comment model
from django.db import models
from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType
from django.conf import settings
class Comment(models.Model):
# Generic relation fields
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
object_id = models.PositiveIntegerField()
content_object = GenericForeignKey('content_type', 'object_id')
# Model specific fields
author = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.CASCADE
)
comment = models.TextField()
created = models.DatetimeField(auto_now_add=True)
# ...
Your reusable generic relation model. The best way is using abstract model classes or mixins. For example, using abstract models:
from django.db import models
from django.contrib.contenttypes.fields import GenericRelation
class Commentable(models.Model):
comments = GenericRelation(Comment)
class Meta:
abstract = True
Your Commentable model:
from django.db import models
class Foo(Commentable, Likeable, ...):
# your stuff
How to use it:
# Add a new comment to Foo
foo = new Foo()
foo.save()
foo.comments.create(author=author, comment="Your comment")
# Retrieve all comments from an specific user no matter the base model
comments = Comment.objects.filter(author=author)
EDIT As #ozren1983 said, each approach has its own downsides, but this is the standard way to do it.
The main advantages are:
You can retrieve all the comments (for example) made in all your commentable models in just one query. Using the approach of having a comment, like, etc table per model, you would need to concatenate a query per model. This could be problematic and a bit challenging if you have a lot of models or if you want to merge the results and order them, for example.
Just one table per functionality (comments, likes) implies just one database migration in case of change. This could be key if your database is huge.
The main disadvantage is the lack of integrity checks of this generic relationship in database. But if you plan to use the django ORM strictly, nothing should be broken.
BONUS: Another approach that many projects use is inheriting the models (one to one relationship) from an specific one called Item or Thread. Then, you can add all the comments, likes, etc functionalities to this model. This is called multi-table inheritance. An example:
from django.db import models
class Thread(models.Model):
pass
class Comment(models.Model):
# Relation with thread
thread = models.ForeignKey(
Thread,
on_delete=models.CASCADE,
related_name="comments"
)
# Model specific fields
author = models.ForeignKey(
settings.AUTH_USER_MODEL,
on_delete=models.CASCADE
)
comment = models.TextField()
created = models.DatetimeField(auto_now_add=True)
# ...
class Foo(Thread):
pass
Unlike using the generic relationships, the main advantage of this method is that, this way, you have database integrity checks.
The main disadvantage is that your database structure could become complex.
Based on my experience and recommendations in Two scoops of Django, I would advise against using GenericForeignKey and GenericRelation. Two big downsides of that approach are:
slow queries
danger of data corruption
Instead, I would use following approach. Let's say you have 3 models:
class User(models.Model):
username = models.CharField(max_length=255)
class Author(models.Model):
name = models.CharField(max_length=255)
class Post(models.Model):
title = models.CharField(max_length=255)
author = models.ForeignKey(Author)
Add abstract Like model, and use it as base class for other models that will implement liking functionality.
class Like(models.Model):
user = models.ForeignKey(User)
date_created = models.DateTimeField(auto_now_add=True)
class Meta:
abstract = True
class AuthorLike(Like):
author = models.ForeignKey(Author)
class PostLike(Like):
post = models.ForeignKey(Post)
Similarly, add abstract Rating model and use it as a base class:
class Rating(models.Model):
user = models.ForeignKey(User)
rate = models.PositiveSmallIntegerField()
date_created = models.DateTimeField(auto_now_add=True)
class Meta:
abstract = True
class AuthorRating(Rating):
author = models.ForeignKey(Author)
class PostRating(Rating):
post = models.ForeignKey(Post)
You can use same approach to enable liking and rating to the Comments model you are using:
from threadedcomments.models import ThreadedComment
class ThreadedCommentRating(Rating):
threadedcomment = models.ForeignKey(ThreadedComment)
class ThreadedCommentLike(Like):
threadedcomment = models.ForeignKey(ThreadedComment)
The django-contrib-comments app, according to documentation, makes use of GenericForeignKey, meaning its own model can create a relation to any other model in your project.
A simple solution would be to just copy that existing functionality, creating your own Like/Rate application based on the same concept (i.e. storing the Like/Rate models in that application's models).
I think you would get very far starting out by forking the https://github.com/django/django-contrib-comments codebase.
(I assume you have searched and failed to find an already existing application that already does this).
I'm trying to create a reusable app where I define some abstract models, and some concrete versions of those models that the user can use if they don't want to inherit the models themselves. If the user does want to create their own subclasses then I don't want Django to create these concrete models.
This is the solution I have at the moment:
myapp/abstract.py
class AbstractModel1:
class Meta:
abstract = True
field1 = models.CharField(max_length=255)
class AbstractModel2:
class Meta:
abstract = True
field1 = models.CharField(max_length=255)
field2 = models.ForeignKey(getattr(settings, 'ABSTRACTMODEL1_OVERRIDE', 'myapp.ConcreteModel1'))
myapp/models.py
if not hasattr(settings, 'ABSTRACTMODEL1_OVERRIDE'):
class ConcreteModel1(AbstractModel1):
pass
if not hasattr(settings, 'ABSTRACTMODEL2_OVERRIDE'):
class ConcreteModel2(AbstractModel2):
pass
Then in the user's app, they can either use the concrete models as provided, or if not then they can create their own subclasses of the model like so:
userapp/models.py
class CustomModel1(AbstractModel1):
extrafield1 = models.CharField(max_length=255)
userapp/settings.py
ABSTRACTMODEL1_OVERRIDE = "userapp.CustomModel1"
Is this the best way to achieve this? Am I setting myself up for difficulties when trying to migrate changes in the subclassed models? What if the user wants to use the provided concrete classes first then migrate to a custom class?
Most of my Django models use the same User Mixin, because of this I would like to dynamically create the related_name for the field.
I would like it to be the class name where TestModel becomes test_models or maybe even a set name from the meta class on the main model.
I have looked at self__class__.__name__ but this give me the name of the User class.
Would it be possible to do something like below, if so how....
class User(models.Model):
user = models.ForeignKey(USER, related_name=META.related_name)
class Meta:
abstract = True
class TestModel(User):
title = models.CharField(max_length=80)
class Meta:
related_name = "test_model"
I think it might be sufficient to handle this like it is documented here.
# myapp/models.py
class User(models.Model):
user = models.ForeignKey(
USER,
related_name="%(app_label)s_%(class)s_related"
)
class Meta:
abstract = True
class TestModel(User):
title = models.CharField(max_length=80)
This way the related name would dynamically become myapp_testmodel_related. Of course you can tweak the name and simplify the pattern, if it is certain that the names can't clash between multiple apps.
I have two models, each has a shared ManyToMany, using the db_table field. But how do I prevent syncdb from attempting to create the shared table, for the second model?
class Model1(models.Model):
othermodels = ManyToManyField('Model2', db_table='model1_model2', related_name='model1_model2')
class Model2(models.model):
othermodels = ManyToManyField('Model1', db_table='model1_model2', related_name='model2_model1')
It's working great in my dev environment, because some of the tables got created piecemeal, as I built it all out. But from an empty database, syncdb throws:
_mysql_exceptions.OperationalError: (1050, "Table 'model1_model2' already exists")
Is there a flag that I'm missing from the second model's field to prevent duplicate table creation? Or am I just doing this entirely wrong?
I also found this solution, which worked perfectly for me :
class Test1(models.Model):
tests2 = models.ManyToManyField('Test2', blank=True)
class Test2(models.Model):
tests1 = models.ManyToManyField('Test1', through=Test1.tests2.through, blank=True)
You don't need to put a ManyToManyField on both sides of the relation. Django will do that for you.
You probably want something more like this:
class Model1(models.Model):
name = models.CharField(max_length=128)
...
class Model2(models.Model):
name = models.CharField(max_length=128)
othermodels = models.ManyToManyField(Model1, through='Model1Model2')
...
class Membership(models.Model):
class Meta:
db_table = 'model1_model2'
model1 = models.ForeignKey(Model1)
model2 = models.ForeignKey(Model2)
When you're working with your models, an instance of Model1 will have a othermodels_set field which is automatically added by django. Instances of Model2 will have othermodels.
class Awesome(models.Model):
one = models.TextField()
class Meta:
# Prevent table creation.
abstract = True
http://docs.djangoproject.com/en/dev/topics/db/models/#abstract-base-classes
It's not what you're looking for, but it's the closest they have I belive. Would it not be simpler to make a view?
Maybe:
class Awesome(models.Model):
one = models.CharField(max_length = 255)
two = models.CharField(max_length = 255)
class AwesomeOne(Awesome):
fieldOne = models.ForeignKey(User, related_name = 'one')
class Meta:
abstract = True
class AwesomeTwo(Awesome):
fieldTwo = models.ForeignKey(User, related_name = 'two')
class Meta:
abstract = True
Then, you can have one table created and override the __getattr__ to block access to the original fields.
In Django ManyToMany are bi-directional by default. The think is that you only have to define it on one model, not on both (and usually you don't need to give a name to the table):
class Model1(models.Model):
othermodels = ManyToManyField('Model2')
class Model2(models.model):
...
That's it. Now syncdb will be happy. For more info: Django docs
The only drawback is, if you use the admin, you will have access to othermodels only in Model1.
Edit
So, if you want to have access to the ManyToMany in both models in the Admin, currently the official solution is to use inlinemodel for the second model. I had also this same problem/need just a few days ago. And I was not really satisfied with the inlinemodel solution (heavy in DB queries if you have a lot of entries, cannot use the *filter_horizontal* widget, etc.).
The solution I found (that's working with Django 1.2+ and syncdb) is this:
class Model1(models.Model):
othermodels = models.ManyToManyField('Model2', through='Model1Model2')
class Model2(models.Model):
othermodels = models.ManyToManyField('Model1', through='Model1Model2')
class Model1Model2(models.Model):
model1 = models.ForeignKey(Model1)
model2 = models.ForeignKey(Model2)
class Meta:
db_table = 'app_model1_model2'
auto_created = Model1
See ticket 897 for more info.
Unfortunately, if you're using South you will have to remove the creation of the app_model1_model2 table in every migration file created automatically.