41 Matching Annotations
  1. Oct 2022
  2. Mar 2022
  3. Jun 2021
    1. Worse still is the issue of “service” layers requiring you to basically build your own ORM. To really do a backend-agnostic service layer on top of the Django ORM, you need to replace or abstract away some of its most fundamental and convenient abstractions. For example, most of the commonly-used ORM query methods return either instances of your model classes, or instances of Django’s QuerySet class (which is a kind of chained-API results wrapper around a query). In order to avoid tightly coupling to the structure and API of those Django-specific objects, your service layer needs to translate them into something else — likely generic iterables to replace QuerySet, and some type of “business object” instance to replace model-class instances. Which is a non-trivial amount of work even in patterns like Data Mapper that are designed for this, and even more difficult to do in an Active Record ORM that isn’t.

      I see what this guy means and he has a point. However, I don't think about reimplementing these things when talking about services on Django. I want a centralized place to store business logic (not glue queries) and avoid multiple developers writing the same query multiple times in multiple places. The name "service" here sucks.

    2. A second problem is that when you decide to go the “service” route, you are changing the nature of your business. This is related to an argument I bring up occasionally when people tell me they don’t use “frameworks” and never will: what they actually mean, whether they realize it or not, is “we built and now have to maintain and train our developers on our own ad-hoc private framework, on top of whatever our normal business is”. And adopting the service approach essentially means that, whatever your business was previously, now your business is that plus developing and maintaining something close to your own private ORM.

      I don't think these two things are even close to be the same thing. Django's ORM is not replaced by services, from what I know services are the ORM with the difference that they are concentrated in a module.

    1. This isn't about writing boilerplate setter properties for each field in the model, but rather about writing methods that encapsulate the point of interaction with the database layer. View code can still inspect any field on the model and perform logic based on that, but it should not modify that data directly. We're ensuring that there is a layer at which we can enforce application-level integrity constraints that exist on top of the integrity constraints that the database provides for us.

      Addresses the issue raise on this tweet. We are not writing getters and setters out of obligation or convention.

  4. Jun 2020
    1. The philosophy behind Flask is that it gives only the components you need to build an app so that you have the flexibility and control. In other words, it’s un-opinionated. Some features it offers are a build-int dev server, Restful request dispatching, Http request handling, and much more.

      Flask isn't as full of features as Django (which makes him lighter), but it still offers:

      • build-int dev server
      • Restful request dispatching
      • HTTP request handling
      • much more...
  5. May 2020
  6. Apr 2020
    1. def save(self, *args, **kwargs): return

      def delete(self, *args, **kwargs): return

      from django.db import models

      class MyReadOnlyModel(models.Model): class Meta: managed = False

    1. To use Gunicorn as your web server, it must be included in the requirements.txt file as an app dependency. It does not need to be installed in your virtual environment/host machine.
  7. Mar 2020
  8. Feb 2020
  9. Nov 2019
    1. REST_FRAMEWORK = { 'DEFAULT_PAGINATION_CLASS': 'rest_framework.pagination.LimitOffsetPagination', 'PAGE_SIZE': 100 }
  10. Oct 2019
  11. Mar 2019
  12. Nov 2018
  13. Oct 2018
  14. Sep 2018
  15. Aug 2018
  16. Dec 2017
  17. Sep 2017
  18. May 2017
  19. Apr 2017
  20. Mar 2017
  21. Feb 2017
  22. Jan 2017
    1. sudo apt-get install libtiff5-dev libjpeg8-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.6-dev tk8.6-dev python-tk

      sudo apt-get install libtiff5-dev libjpeg8-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.6-dev tk8.6-dev python-tk

  23. Aug 2016
    1. 1.8 LTS 1.8.14 December 1, 2015 Until at least April 2018

      Django 1.8 LTS support until at least April 2018