This question already has answers here:
Django admin search/filter functionality as a page table
(2 answers)
Closed 5 years ago.
My goal is to develop a web-application that would retrieve data from a database and display them in a table.
I'm new to the web-development, this task is not my main goal, therefore, I'd like to spend minimum efforts for it.
I've chosen Django for this task. I've got familiar with its admin site from the official tutorial, and can conclude that it has all required functionality (retrieving, sorting, filtering, search).
In parallel, I've installed django-tables2. It requires much more efforts, for example, writing CSS templates, while admin has all included.
Is it possible to use that admin site like ordinary web app just to display data, without adding or deletion?
Yes, you can do that. I have done it before. The challange is to create your target database structure. Django has an manage.py inspectdb command you can use to generate models from the target database. You would only need to override the ModelAdmin, so you cannot save it.
class CustomAdmin(admin.ModelAdmin):
def save_model(self, request, obj, form, change):
pass
Related
The age-old question: How can I automatically save last_modifed_user in django models?
I found in several places this general process how to do it using thread local. I'm hesitant to simply implement it that way because I'm not entirely sure of the consequences it has and because all these posts are old.
Is using thread local still the "recommended" way of doing this in django 3? Or does django3 have a better options of doing it?
No, this hasn't changed. Simply because separation of concern is an architectural principle of MVC (model-view-controller), which is also how Django (model-view-template) and most web frameworks with ORM are architected. Models know nothing about the request, it's not available (and in many cases there isn't a request at all when a model is saved, think of management commands or regular tasks running in the background).
The alternative to thread local is to make sure you implement it yourself in the controller layer (view layer in Django):
Create a view mixin that you can mix with all the generic views that use the ModelFormMixin to save the user into the model (ModelFormMixin.form_valid()). Or combine it with a form mixin where the user is passed to the form (FormMixin.get_form_kwargs()) and saved when the form is saved (ModelForm.save()).
Create a ModelAdmin mixin that does the same when saving a model in the django admin site.
This of course means someone on your team may forget to do it when creating new views and forms. The link you posted contains an answer as to the advantages and disadvantages of using thread local.
I am creating a project in django and django rest framework. Its an api for an angular app. The database setup consists of multiple databases. one is default database, all the django tables reside in this database; rest of the databases belong to a type of a user, each user is supposed to have a separate database. So, all the user related data goes to its separate database. To implement the selecting database dynamically, user object has an extra field to store the database to write to.
from django.contrib.auth.models import AbstractUser
class CustomUser(AbstractUser):
"""Custom User model."""
database= models.CharField(max_length=9)
Reason for doing this was performance improvement as each database is separate, ListView and DetailView would work faster than if the data was stored in the one database only.
I know I can choose a database to store by using the using method on the model manager. In the rest api things work fine and data is being stored in their separate databases, but I end up overriding methods that django has defined. Its adding development cost to the project. Foreign keys and ManytoMany keys needs to be resolved with the current database of the user, which is not happening as I have customized the database setup. Also, my code cant be as good as theirs :p , as they have written django over the course of many years.
I have overwritten many querysets already, but django still uses default database many times. If only I could use the request object in the model manager of django models to swap the default database on per request basis, things would be different i think.
My questions are -
Is there a way to access the request object in the model manager? I could do something to the effect of below code.
class CustomManager(models.Manager):
def get_queryset(self, request):
return super(CustomManager, self).using(request.user.database).get_queryset()
Model manager has _db property that could be used to select database. Would overriding it is advised? if yes, how and where in the code?
Is there a better way to implement the separate databases?
Thanks in advance.
Regards
Using a database router is recommended in Django docs, but the problem is it only accesses the model class.
Found a couple of questions related to the problem of switching databases dynamically. This post has a solution that would solve the problem of passing the request.user or any other parameter by using a threading.local instance.
Someone created a reusable plugin even for this - https://github.com/ambitioninc/django-dynamic-db-router
Hope that helps.
I'm learning Django on Ubuntu 13.04, Python 2.7, Django 1.5, Postgres 9.2,
Bootstrap 3.0. I'd like to achieve a combination of the tutorial example Polls app with django-authentication.
As my first effort I got the Polls app working from the Django 1.5 tutorial. I then installed django-registration 1.0 and these templates to make it work. I chose that package for authentication as opposed to django-allauth as a result of my question on authentication framework.
Now I want to integrate Polls and django-registration to record a set of results per user. After the poll results have been collected the admininstrator uses Django Admin interface to run a script to analyse the results (e.g. compute some statistics) and send an email to a subset of all users.
I briefly looked at two existing projects that looked like could get me there out of the box.
Light Bird's Questionnaire App was too complicated using a custom library of modular class based views. I'd like to keep it as simple as possible, using as much of out-of-the-box Django 1.5 functionality as possible for ease of maintenance and initial design.
Pinax web framework on top of Django, although a great idea, seems to be stuck in dark ages of 2011 with latest code supporting only Django 1.4 and Bootstrap 2.x. Starter projects don't look that useful and documentation isn't flash either.
Based on the above it looks like I'll have to do the integration of Polls and registration manually. At first pass I was thinking roughly the following:
The poll & choice could be simplified down to just a numeric answer to a question.
At database level we would need a separate table.
The primary key would be the userid.
Each column would store one answer per.
I'm guessing this would need a class PollsResults in model.py that would include defining the primary key as User, which should exist via django-registration.
Exactly how to do that and what follows gets a bit hazy to me at the moment.
I'm sure the above is a simple exercise for a Django developer. Could anyone give me some starting hints or even better an existing project that does something similar?
It looks like you're slightly underestimating the power of using a framework such as django. For example, you don't really need to worry too much about tables in the database or what will be their primary keys, because django's Object Relational Mapper (ORM) takes care of a lot of that for you.
If you want to connect two models (database tables) in django you can use a foreignkey like this:
class ThingOne(models.Model):
name = models.CharField(max_length=50)
class ThingTwo(models.Model):
thing_one = models.ForeignKey('ThingOne')
The quotes around 'ThingOne' in my ForeignKey are actually unnecessary because the ThingOne model has already been defined, but I like to use quotes anyway because it means your ForeignKeys will also work for models defined below (in your code) the model linking to them.
You therefore just need to add a relationship between your Polls and User models. If one user might have many poll results you should probably use a ManyToManyField instead of a ForeignKey but the principle is the same. That should be enough to get you started.
I have models with datetimefields and timefields. When the user interacts with these fields in a form they often just need to enter the current time. I need a now link almost exactly like what shows up in the django admin, so the user can just click it and the current time gets put in the field.
I tried looking through the django source but it seems to utilize some frontend javascript which I'm not very familiar with. Is there a simple way to make a widget that can be easily used in a timefield and datetimefield?
So this is not on the admin panel? As in on the site? Then this is not really a question to be posed to Django, I suggest tagging javascript. If you are unfamiliar with javascript, then tag jquery, they have things for this.
In case you're lazy, here's a start:
Here
jQuery premade
Javascript methods
Sorry, but this is more of a UI issue than a Django issue. Hope I helped, though.
This question already has answers here:
Django - specify which model manager Django admin should use
(4 answers)
Closed 8 years ago.
I need to add a way to view all products entered into the site. Right now they are filtered by being enabled=True and this only shows the products enabled. I'd like to be able to list ALL products and enable and disable them in the admin. Thanks in advance!
Model:
class ProductManager(models.Manager):
"""
Filters enabled product
"""
def get_query_set(self):
return super(ProductManager, self).get_query_set().filter(is_enabled=True)
The Django docs are quite explicit on this. Especially if you're new to the world of Django, you should be wrapping yourself up in the docs like a warm blanket. Read through them if you have time (try to make time), but if you can't, just search Google with "django" and whatever the issue you have is. 99% of the time, the first result is a page from the Django documentation and contains exactly the info you need.
That said, the docs say on this issue:
If you use custom Manager objects, take note that the first Manager Django encounters (in the order in which they're defined in the model) has a special status. Django interprets the first Manager defined in a class as the "default" Manager, and several parts of Django (including dumpdata) will use that Manager exclusively for that model. As a result, it's a good idea to be careful in your choice of default manager in order to avoid a situation where overriding get_query_set() results in an inability to retrieve objects you'd like to work with. (emphasis mine)
That's exactly what you're experiencing. Look again at the first sentence of the quote above. Django uses the first manager it encounters as the "default" manager for various parts of its machinery, including the admin. So the solution is to simply add a non-filtered manager before your custom manager. The best way to do that is to simply use the standard manager that Django adds automatically if you don't provide your own.
objects = models.Manager()
product_manager = ProductManager()
Done. The admin will now list all products because it will use the first, standard manager as the default.