I am facing a problem from days, but, no matter how much I keep searching, I could not find any solution here or anywhere in the web.
So here it is: I am developing a website for some sort of institution which offers teaching courses. I am using WAGTAIL and I am structuring the classes this way:
class Course(Page):
...
content_panels = Page.content_panels
class Exam(Page):
#fields
content_panels = Page.content_panels + [
#fields
InlinePanel('preparatory_exam', heading='Preparatory Exams'),
]
class PreparatoryExam(Orderable):
page = ParentalKey('Exam',
on_delete=models.CASCADE,
related_name = 'preparatory_exams',
)
name = models.ForeignKey(
Exam,
on_delete=models.CASCADE,
blank=True,
null=True,
related_name = 'preparatory_exam',
)
I also structured the ADMIN section PAGES this way:
\COURSE_1_PAGE
\-----------\EXAM_1
\-----------\EXAM_2
\------------------\Prep exam 1
\------------------\Prep exam 2
\-----------\EXAM_3
...
\COURSE_2_PAGE
\-----------\EXAM_1
\-----------\EXAM_2
\-----------\EXAM_3
....
So, the problem is: is there any way to pass a custom queryset to the inline dropdown box when choosing the preparatory exams for a certain one? What I want is to restrict the set to the exams present in the same Course.
I could do that with a limit_choices_to added to the foreignkey field, but AFAIK, it would be a "static" filter, because it would be related to the model and not to its istances, so it would be the same for every newly instantiated exam...
One first- highly unsatisfactory - solution would be to change the InlinePanel with 2-3 FieldPanels (generally an exam does not need more than 2-3 other prep exams)...
Another UGLY solution would be explicitly defining Course_1, Course_2 and so on classses, but the problem here is that every year I would have to add another class, because they set up a new course every year!
So it leaves me not a lot of choices: overriding somehow (but i'm in the dark) the InlinePanel object behavior, or change the way I designed the site.
Can anyone help me? Thank you very very much!
One pragmatic option might be to use "ordinary Django views" to build this particular part of the application, borrowing Wagtail visual designs freely so that everything continues to look the same to the end-user. Given that you are building a display of a very rigid data-structure - course, exam, etc., as opposed to "free-form content," this is probably how I would choose to do it.
(Note that Wagtail template tags might or might not work properly when Wagtail isn't the one driving the page display. I'd recommend implementing your own, of course freely copying from the Wagtail source-code for inspiration.) In the end, the user would not perceive a difference, and you can very freely develop URLs that would send the user to a Wagtail-managed target page, e.g. the course-descriptions and exams themselves.
Another pragmatic option is to use Django template-tags to construct portions of the display that are otherwise managed by Wagtail, although this gets maybe a bit more complicated. Since Django is underneath the whole thing, "Django rules still apply."
Related
Let's imagine I'm building a Django site "CartoonWiki" which allows users to write wiki articles (represented by the WikiArticle-model) as well as posting in a forum (represented by the ForumPost-model). Over time more features will be added to the site.
A WikiArticle has a number of FileUploads which should be deleted when the WikiArticle is deleted. By "deleted" I mean Django's .delete()-method.
However, the FileUpload-model is generic -- it's not specific to WikiArticle -- and contains generic file upload logic that e.g. removes the file from S3 when it's removed from the database. Other models like ForumPost will use the FileUpload-model as well.
I don't want to use GenericForeignKey nor multi-table inheritance for the reasons Luke Plant states in the blog post Avoid Django's GenericForeignKey. (However, if you can convince me that there really is no better way than the trade-offs GenericForeignKey make, I might be swayed and accept a convincing answer of that sort.)
Now, the most trivial way to do this is to have:
class FileUpload(models.Model):
article = models.ForeignKey('WikiArticle', null=True, blank=True, on_delete=models.CASCADE)
post = models.ForeignKey('ForumPost', null=True, blank=True, on_delete=models.CASCADE)
But that will have the FileUpload-model expand indefinitely with more fields -- and similar its underlying table will gain more and more columns as new models in the system start using FileUpload. This feels suboptimal both in terms of data-modeling, but also in terms of separation-of-concerns -- the FileUpload-model and table is being changed while no actual new functionality is being added to it.
My preference would really be to go the other way around:
class WikiArticle(models.Model):
uploads = models.ManyToManyField('FileUpload')
But this doesn't solve the deletion issue: If I .delete() a WikiArticle the corresponding FileUploads won't be deleted. I've tried various setups with through-models, but none seem to solve it. What I really need is a OneToMany-field -- a sort of reverse ForeignKey to indicate the ownership in the right direction without polluting the generic/reusable model.
Should FileUpload really instead be a field? Or perhaps an abstract model? (WikiArticleFileUpload, ForumPostFileUpload, and so on...).
I realize that a true ManyToManyField with implied ownership would no longer really be a ManyToManyField since the field implies sharing. E.g. a FileUpload could technically be referenced by multiple WikiArticles, so you could be removing FileUploads from other objects rather on top of the one you're deleting. The question still stands though -- it seems I need a OneToManyField to model this in a nice way.
You probably have a couple of options to solve your problem, but it also requires on the exact requirements of your application.
Using a GenericForeignKey in this situation is probably fine, escpecially due to the fact that you do not know how many other models will use your upload model. Of course as mentioned in the linked blog post eg. doing plain SQL queries might be harder but it's on you to decide if that's a problem for your use case.
Also using inheritance might be an option, so that all the referenced models inherit the relation to the upload model from a common ancestor. This might have a small impact performance-wise because you Django would need to join the tables of the models but the impact might still be not that big. On the other hand this approach might also have some advantages if eg. your articles and posts have other stuff in common as well and you could easily do stuff like "show all new posts and articles (together)".
If you handle deletion yourself as mentioned in the previous answer you can also add ManyToMany fields yourself but also consider that this method also has some disadvantages in common with using generic foreign keys (eg. a lot of stuff to join in the database...)
Probably it's fine that you just use a GenericForeignKey, especially if the number of models that use your "generic" model gets bigger (eg. more than 3-5). All in all this sounds pretty much like a use case GenericForeignKey was made for (imagine the uploads being something like "tags" belonging to the posts).
ManyToMany fields are symmetrical, even though you define them on one model with an (explicit or implicit) related_name on the other.
I can think of two methods to clean up while, or after, WikiArticles are deleted. The first is to periodically search for and delete "orphan" FileUploads. At its simplest, (assuming a related_name of articles)
deleted = FileUpload.objects.filter( articles__isnull=True).delete()
The other is to explicitly process the related articles during deleting of the article. It's straightforward to subclass the object's delete method, but this is not the only way to delete an object (bulk_delete, for example, bypasses this). Anyway,
def delete( self, *args, **kwargs):
article_pks = self.uploads.all().values_list('pk', Flat=True)
response = super().delete( *args, **kwargs)
FileUpload.objects.filter(
pk__in = article_pks, articles__isnull=True) .delete()
return response
(or even just execute the "periodically" code above, for every article-deletion, which will also tity after any deleted though othr channels)
Please thoroughly test this if you use it. Delete operations which don't do precisely what is wanted are the scariest sorts of bug!
Let's imagine a I have a simple model Recipe:
class Recipe(models.Model):
name = models.CharField(max_length=constants.NAME_MAX_LENGTH)
preparation_time = models.DurationField()
thumbnail = models.ImageField(default=constants.RECIPE_DEFAULT_THUMBNAIL, upload_to=constants.RECIPE_CUSTOM_THUMBNAIL_LOCATION)
ingredients = models.TextField()
description = models.TextField()
I would like to create a view listing all the available recipes where only name, thumbnail, preparation_time and first 100 characters of description will be used. In addition I will have a dedicated view to render all remaining details for a single recipe.
From the efficiency point of view, since description may be a long text, would it make sense to store the extra information in a separate model, let's say 'RecipeDetails' which would not be extracted in a list view but only in a detailed view (maybe using prefetch_related method)? I am thinking about something along:
class Recipe(models.Model):
name = models.CharField(max_length=constants.NAME_MAX_LENGTH)
preparation_time = models.DurationField()
thumbnail = models.ImageField(default=constants.DEFAULT_THUMBNAIL, upload_to=constants.CUSTOM_THUMBNAIL_LOCATION)
description_preview = models.CharField(max_length=100)
class RecipeDetails(models.Model):
recipe = models.OneToOneField(Recipe, related_name="details", primary_key=True)
ingredients = models.TextField()
description = models.TextField()
In my recent online searches people seem to suggest that OneToOneField should be used only for two purposes: 1. inheritance and 2. extending existing models. In other cases two models should be merged into one. This may suggest I am missing something here. Is this a reasonable use of OneToOneField or does it only add to a complexity of an overall design?
inheritance
Don't do that, because inheritance would only be useful if you have baseclass/subclass relationship. The classic example is animal and cat/dog, in which the cats/dogs all have some basic properties that could be extracted, but your Recipe and RecipeDetail don't.
From the efficiency point of view, since description may be a long
text, would it make sense to store the extra information in a separate
model
Storing extra information in a separate model doesn't improve any efficiency. The underline database would create something like a ForeignKey field and plus unique=True to make sure the uniqueness. As far as I concerned, OneToOneField is only useful when your original model is hard to change, e.g., it is from third-party packages or some other awkward situations. Otherwise I still consider adding them to the Recipe model. In this case, you can manage your model easily while avoiding having some extra lookups like recipe.recipedetail.description, you can just do recipe.description.
No, it's not reasonable to split your Recipes. First, your model should contain all properties for being a "Recipe" (and a recipe without ingredients is not a recipe at all). Second, if you want to improve performance, then use the Django's Cache Framework (it was created exactly for improving performance issues). Third, keep it simple and do not over-engineering your development cycle. Do you really need to improve performance right now?
Hope it helps!
First mistake in development, you are thinking in efficiency before your first version is running.
Try to have now a first version, that runs, and later you can think in be more faster based in use cases with your first version. After this you can check if a model and relations, or only a new field in model or using Django Cache for views can do the work.
Your think in efficiency first will be "de-normalize" your Database btw, when one update in the model with full description is done, you need to launch one update to the model with "description-preview" field. trigger in database level? python code for update in app level? nightmares in code design ... before your code runs.
For the django admin site, for example, I have a model as follow:
class Book(models.Model):
...
author = models.ForeignKey(Author)
...
(to make it simple, we assume each book only has one author)
So when I try to add a new Book in admin site, author will display as a dropdown list and I can roll and select the author it belong to.
The problem is that when you get a lot of Authors, it will be hard to find one you want. So someone suggest to use "raw_id_fields" to solve the problem.
I think it works. However, I want better. I want something like a search box inside the same page rather than pop a page to do so. And probably keep the dropdown list at the same time.
What I am thinking is that I probably need to write some customized template. I did some research on this, but I am still confused. I want to know which template I should override and what kind of approach I should use.
Thanks for any help!
There are several type-ahead / autocomplete plugins for Django admin that will take the place of the standard drop-down list. Here's a couple: https://github.com/artscoop/django-admin-autocomplete or https://github.com/sxalexander/django-autocomplete
I have come across this situation several times.
If I have something that I generally like in contrib, but I want to make one minor tweak to a field, what do I do?
I don't want to throw out the baby with the bathwater.
To give an example, take auth.user (which, contrary to what seems to be popular opinion on the matter, I regard as being generally on the right track). I want to create a through model for auth.user's relationship to auth.group.
How can I do this without modifying django?
auth.User is a special case since the User model is tied in to lots of parts of Django and it is tricky to modify this (though not impossible, as others have pointed out). My best advice would be to question why you don't want to modify Django source. You can pull source for either the head of the devel branch or get a tagged version corresponding to a numbered release. Modify the code at will and use some combination of svn update, svn diff, and svn patch to migrate your changes.
Next, modifications to contrib modules are possible in your code, since Python is interpreted and dynamically typed. If you do this, you'll need to take into consideration parsing/processing order since some operations may already have utilized the original module. Below is an example I got from someone else (probably here on SO) of how to add a convenient forward reference from User to the associated Profile object:
from django.db.models import Model
from django.contrib.auth.models import User
class UserProfile(Model):
user = ForeignKey(User, unique=True)
phone = CharField(verbose_name="phone number", blank=False, max_length='20')
User.profile = property(lambda u: UserProfile.objects.get_or_create(user=u)[0])
I don't think this strategy will work for adding/modifying ModelFields in django.contrib.auth.models.User, however.
Finally, for your specific example of associating groups with a user, you should see if this is possible by creating a UserProfile model. My initial guess is that it should be pretty easy.
There's probably an obvious way to do this that I'm missing, so sorry for the noobish question.
I've got models like this:
class Speaker(models.Model):
name = models.CharField(max_length=50)
class Talk(models.Model):
title = models.CharField(max_length=50)
speaker = models.ForeignKey(Speaker)
How can I elegantly get a list of all speakers who've given talks?
At present I'm doing horrible things with getting the list of all Talks and looping through them, because I can't see an easy way of doing it using Django's ORM.
Speaker.objects.exclude(talk=None)
or
Speaker.objects.filter(talk__isnull=False)
Edit:
Looking at the underlying SQL (by adding .query.as_sql() on the end of the expression), it seems the latter form is significantly more efficient. The former does a completely unnecessary subquery.
I suspect this is a bug, as the first form was introduced in the massive queryset refactor that took place just before version 1.0, and is supposed to be the preferred form.