LazyPrimaryKeyRelatedField
When you change dynamicaly the objects manager on your Model class, you may want to have serializers take it into account.
- DRF
- PrimaryKeyRelatedField
When you change dynamicaly the objects manager on your Model class, you may want to have serializers take it into account.
This manager use a local (in python dicts) cache for efficiency. It caches get requests and is better used with a context manager. I based my work on this previous snippet : https://djangosnippets.org/snippets/815/
MYSQL Full Text Expression
This is a Python 3 re-write for https://djangosnippets.org/snippets/2117/
I'm typescript frontend developer and i was interested in standartizing API server responses. I've tried Django for one of my projects. I've build my API and splited it into Django apps aiming at possible migration to [link >] [Microservices](https://www.youtube.com/watch?v=0iB5IPoTDts) [<] later. The problem I've faced is a difficulty of standartization API responses not only in multiple views, but for all composition of JSON-oriented django-apps which can only be made with middleware. I have put all the links to everybody could familiarize with Django framework conceptions used here. Also, I suggest to familiarize with [link >] [origin solution] (https://djangosnippets.org/snippets/10717/) [<]. The main difference is that in all my DRF JSONRenderers I do not need to wrap fields in 'result' or 'results' nested JSON. I do not get messed with result and results. If I expect an array, I just check additional pagination fields. I did not used a pagination section in my project, still i've left opportunities for that according to [link >] [origin solution] (https://djangosnippets.org/snippets/10717/) [<. Ypu can also find a paginator code fro DRF there.
A proxy for Django queryset attempting to avoid boilerplate code with ifs and avoid bugs when affectation of result is not done.
It may save you some time if you're in the case of this link : https://stackoverflow.com/questions/11801363/django-q-with-joins-functioning-incorrectly-bug It worked for me at least.
Useful for models with fields like `finished` or `last_updated`
Python 3.8's Assignment Expressions, aka the Walrus operator, feel like an excellent pattern for checking optional environment variables that are only needed to initialize a library like Sentry.
es solo un ejemplo
This is an updated of version snippets: * [https://djangosnippets.org/snippets/10489/](https://djangosnippets.org/snippets/10489/) * [https://djangosnippets.org/snippets/1376/](https://djangosnippets.org/snippets/10489/) Tested to with with Django 3.2 With this template loader you can extend templates from built-in Django apps such as Django admin. Example: {% extends "admin:admin/index.html" %} {% block sidebar %} {{block.super}} <div> < h1>Statistics< /h1> < a href="/admin/station/stats/">Published Stations< /a> </div> {% endblock %} Configuration: TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [ 'your_app/templates' ], 'OPTIONS': { # (...) # See: https://docs.djangoproject.com/en/3.2/ref/templates/api/#django.template.loaders.cached.Loader 'loaders': [ ('django.template.loaders.cached.Loader', [ 'django.template.loaders.filesystem.Loader', 'django.template.loaders.app_directories.Loader', 'your_app.template_loaders.SpecificAppTemplateLoader', ]), ], }, }, ]
Automatically setup raw_id_fields ForeignKey & OneToOneField
A minimally invasive Select widget that looks and acts like a disabled select input, but still submits with the form. It works by rendering the form as disabled, and supplements it's output with a hidden input field with the same name and value. Tested in Django 3.0, probably works in Django 1.11+
Third party services (e.g. Stripe) optionally sign webhook events to verify it is them sending events. If the third party you use does not provide an SDK or official library for verifying signatures, you can manually verify the signature with this snippet.
This example below to setup default language code as `id` (Indonesian).