Serializers

Iba a preguntar ¿Por qué Pablo hace

from rest_framework import serializers

en lugar de

from rest_framework.serializers import Serializer

?
Pero caí en cuenta que Pablo usa los Fields dentro de serializers y me di cuenta que muchas veces por eso es importante traer todo el módulo xD

Serializando modelos con campos/relaciones ForeignKey o ManytomanyFields

https://es.stackoverflow.com/questions/5419/django-rest-framework-serializando-modelos-que-tienen-campos-relaciones-foreignk#=

Si uno hace buen uso de los fields en el modelo, no es necesario reescribirlos en el serializer. se puede usar Modelserializer para que los field usados en el serializer sean iguales a los del modelo:

from rest_framework.serializers import ModelSerializer
from profiles.models import Profile


class UserSerializer(ModelSerializer):
    class Meta:
        model = Profile
        fields = ('__all__')

Por lo que entiendo estos archivos son una base donde se realiza toda la configuración general, si es así entonces estos archivos los puedo usar para cualquier otro proyecto??
O sea aún no comienza a realizar las aplicaciones particulares del proyecto, no??

Por lo que entendi aquí esta mostrando toda la configuración base para el proyecto y que puede servir para cualquier proyecto.
Si es así entonces puedo usar todo estos archivos para otro proyecto???
Esto esto así o estoy equivocado??
Saludos

Para que el serializer filtre solo los publicos:

serializer = CircleSerializer(circles.filter(is_public=True), many=True)

me quedaron un par de dudas en el serializer ya que no me queda muy claro la diferencia entre poner el serializer con data Serializer(data=tu_objeto) a pasarlo sin el data Serializer(tu_objeto). cuando se manda data puedo hacer uso de is_valid pero si no lo paso no … como puedo validar cuando no le paso data= ya que si intento serializar una tupla si mando data debe ser un array pero sin data puedo mandarlo sin problema pero no puedo usar la funcion is_valid()

Tengo entendido que uno de los principios de Django y Python en general es DRY, evitar repetirse.

Ahora, veo que agregar validadores a nivel de la vista a través de los Serializers se hace para evitar que la validación llegue al modelo y sea propagada de vuelta a la vista, pero al mismo tiempo estamos duplicando la definición de la validación de los campos.

Entonces, entiendo que para este caso, esta duplicidad implica muy poco riesgo de tener que actualizarla de forma constante, ya que cambiar validaciones de modelos y/o modificar columnas de una tabla no es una acción demasiado frecuente. Entonces por la parte de DRY, creo que es muy aceptable romperlo un poco aquí.

Pero lo que no comprendo aún, es, ¿qué ventajas nos ofrece el que la validación no llegue hasta el modelo? Mi intuición me dice que al hacerlo de esta forma es más fácil trabajar con Django RestFramework.

No estoy muy seguro, ¿ustedes que piensan?

DRF es excelente, que manera de ahorrar tareas tan repetitivas en la creacion de una API

Algun simil a este proyecto pero con MYSQL??

Es hermosooooo DRF. 😍

In computing, serialization or serialisation is the process of translating a data structure or object state into a format that can be stored or transmitted and reconstructed later.

CreateCircleSerializer code

CircleSerializer code