Bienvenida

1

Todo lo que aprender谩s sobre Django

Cimientos

2

Arquitectura de una aplicaci贸n

3

The Twelve-Factor App

4

Codebase: Settings modular

5

Codebase: Dependencias y archivos de docker

6

Codebase: Docker

7

Setups alternativos

Modelos

8

Herencia de modelos

9

Proxy models

10

App de usuarios

11

Organizando modelos en un paquete de Django

12

Creando el modelo de perfil de usuario

13

Soluci贸n del reto: arreglando la migraci贸n de users a user

14

Aplicaci贸n y modelo de c铆rculos

15

Migraciones y admin de c铆rculos

Introducci贸n a Django REST Framework

16

Aprende c贸mo construir tu propio API con Django Rest Framework

17

Vistas, URLs y Parsers de DRF

18

Serializers

19

Buenas pr谩cticas para el dise帽o de un API REST

20

Request, response, renderers y parsers

Real DRF

21

Autenticaci贸n y tipos de autenticaci贸n

22

APIView

23

Creando el token de autorizaci贸n

24

User sign up

25

Limitar login a usuarios con cuenta verificada

26

Configurar env铆o de email

27

Instalar PyJWT y generar tokens

28

Verificar cuenta usando JWT

29

Actualizar modelo de circle (membership)

30

Crear CircleViewSet

31

A帽adiendo autorizaci贸n y paginaci贸n

32

Creaci贸n de circulos

33

Update de c铆rculo, custom permissions y DRF Mixins

34

Migraci贸n de vistas de usuarios a ViewSets

35

Detalle de usuario

36

Update profile data

37

List members - Recursos anidado

38

Retrieve destroy member

39

Modelo de invitaciones y manager

40

Obtener invitaciones de un miembro

41

Unirse a grupo

42

Filtrado

43

App de rides y modelos

44

Implementar la publicaci贸n de un ride

45

Validaci贸n de campos de un serializer

46

Listado de rides

47

Editar un ride

48

Unirse a viaje

49

Terminar viaje

50

Calificar viaje

Tareas as铆ncronas

51

驴Qu茅 es Celery?

52

Creando tarea as铆ncrona

53

Creando tarea peri贸dica

Testing

54

Python unittest y Django TestCase

55

DRF APITestCase

Django Admin

56

Admin actions: Modificar datos de un query

57

Admin actions: Regresando una respuesta HTTP

Deployment

58

Instalaci贸n de la aplicaci贸n

59

Configuraci贸n del dominio en Mailgun y del Bucket en Amazon S3

60

Configuraci贸n final de Docker Container usando Supervisor

61

Tutorial de despliegue de la aplicaci贸n

62

Futuros pasos y cierre del curso

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

Creando el modelo de perfil de usuario

12/62
Recursos

Aportes 19

Preguntas 7

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

campos de AbstractUser

  1. username (CharField)

  2. first_name (CharField)

  3. last_name (CharField)

  4. email (EmailField)

  5. is_staff (BooleanField)

  6. is_active (BooleanField)

  7. date_joined (DateTimeField)

campos de AbstractBaseUser

  1. password (CharField)
  2. last_login (DateTimeField)
  3. is_active = True

Aqui una lista frecuente de comandos que usamos de Docker:

Processes : docker-compose -f local.yml ps
Stop app: docker-compose -f local.yml down
Enviroment var: export COMPOSE_FILE = local.yml
Build: docker-compose -f local.yml build
Run app: docker-compose -f local.yml up
Run service command: docker-compose run --rm SERVICE COMMAND
Stop service: docker rm -f SERVICE
Remove volume: docker volume rm -f <ID>
Run one service: docker-compose run --rm --service-ports SERVICE

Lo mejor para el profile es usar on_delete=CASCADE, porque se esta relacionando informaci贸n muy especifica al parent model,es decir al usuario. Y si este se borra no tiene sentido seguir manteniendo esa informaci贸n especifica.

Si se estuviera hablando de un comentario, o algo por el estilo, la mejor opcion podria ser on_delete=SET_NULL.

Creo que ser铆a bueno usar `admin.StackedInline``` para que al crear el` usuariose cree tambi茅n `` `profile.

Por qu茅 CustomUser hereda de UserAdmin y ProfileAdmin hereda del tipico ModelAdmin?

creo que para no estar borrando y creando contenedores o corriendo de nuevo el compose, lo mejor era 鈥渄ockerizar鈥 el proyecto al final, cuando estuviera listo, creeria yo que era mejor asi.

si hablaramos de un sistema en producci贸n, lo ideal ser铆a no borrar los usuarios y la informaci贸n relacionada a ella. A cambio creo que estar铆a mejor incluir en el modelo un atributo 鈥渋s_active鈥 para activar/desactivar cuentas鈥 igual agregar铆a como argumento el tema de la auditor铆a (historial de la informaci贸n que se pueda estar manejando en el proyecto)

Creo que dejar el default de la reputaci贸n en 5 invalida un poco el prop贸sito de 5 estrellas siendo una buena reputaci贸n, de pronto un 3.5 o 3.0 como valor inicial sea mejor en este caso, o eso opino yo (en este caso no importa mucho porque e es una aplicaci贸n de prueba)

Creo que asi se entiende mejor:
Por si no fui claro; me refiero a poner el nombre del atributo justo antes de asignarlo. En: to = ...
Creo que asi se entiende mejor 馃槂

Hola,
Alguien incluy贸 un dato tipo DateField y lo quiso colocar como nulo?.. por ejemplo en el caso de querer guardar la fecha de nacimiento.

El c贸digo fuente tiene una variable que no permite tener ese campo como nulo鈥

Al final 鈥omo se podr铆a resolver eso?

Creo que una buena idea para la reputaci贸n ser铆a colocarla como nula hasta que haga su primer ride鈥 pienso que es lo m谩s justo

En cuanto a el on_delete:

驴C贸mo juega esto con el GDPR?
驴Todav铆a se pueden mantener los datos incluso cuando el usuario borra la cuenta?

Pregunto es por que los datos del perfil del usuario pasar铆an a ser anonimos ya que se borra el user, lo que quedar铆a ser铆a la informaci贸n sobre su perfil sin estar vinculada a ning煤n usuario espec铆fico

Yo opino que no debe tener reputaci贸n, es como si no ha hecho nada pues no le calificamos nada

Cuando el cambia la versi贸n de django y uno desea instalar el proyecto no te deja que curioso no.

En mi caso pienso que no seria buena idea eliminar toda la informacion de usuario debido aque si estoy en un sistema que trabaje por subscriptor necesito saber quien fue ese usuario si un d铆a se da de baja y decide reingresar nuevamente.

Empez贸 muy bien el curso en el v铆deo uno, pero de ah铆 hasta este punto, el curso es b谩sico u.u , espero ense帽e algo realmente avanzado mas adelante. as铆 como la configuraci贸n del proyecto.

Creo que a lo que nos invita pablo trinidad en cuanto cuando usar CASCADE, SET_NULL, SET_DEFAULT鈥 depende mucho del caso de uso pero lo que si se es que si dices que solo se usa casade te falta mucho practicar para darte en que casos hay que aplicar otras opciones

Como hago si no quiero usar el username es decir borrarlo?

en el curso b谩sico las clases heredaban de models.Model, aqu铆 por que no?