Filtros objetivos

[luisaferreirass]

No description provided.

[DevlTz]

Fala Lu, dei olhada no código e testei o que vc subiu e queria q vc desse uma olhada aqui.

DRF = Django Rest Framework

---

1. Model Properties sem dono

A IsPropertyOwner nas views faz essa checagem:

if obj.owner_id != request.user.id:

Mas o model Properties não tem nenhum relacionamento com a tabela de usuários. ( Ou tem??)
O Django lança um AttributeError assim que bater nessa linha. Precisa adicionar
o campo no model:

owner = models.ForeignKey(
    settings.AUTH_USER_MODEL,
    on_delete=models.CASCADE,
    related_name="properties"
)

---

2. Serializers sem create() sobrescrito

O PropertiesSerializer tem os relacionamentos aninhados declarados:

rooms = RoomsSerializer()
condo = CondoSerializer()
rooms_extras = RoomsExtrasSerializer()

O DRF não sabe salvar dados em múltiplas tabelas ao mesmo tempo por padrão.
Um POST vai lançar uma exceção de erro. Precisa sobrescrever
o create() no serializer pra ensinar o Django a salvar na ordem certa
— primeiro os relacionados, depois o imóvel:

def create(self, validated_data):
    rooms_data = validated_data.pop("rooms")
    rooms_extras_data = validated_data.pop("rooms_extras")
    condo_data = validated_data.pop("condo", None)

    rooms = Rooms.objects.create(**rooms_data)
    rooms_extras = RoomsExtras.objects.create(**rooms_extras_data)
    condo = Condo.objects.create(**condo_data) if condo_data else None

    property = Properties.objects.create(
        rooms=rooms,
        rooms_extras=rooms_extras,
        condo=condo,
        **validated_data
    )
    return property

---

3. Nomenclatura dos campos ForeignKey com _id

# Tá atualmente assim
rooms_id = models.ForeignKey(...)
rooms_extras_id = models.ForeignKey(...)
condo_id = models.ForeignKey(...)

Quando você coloca _id no nome de uma ForeignKey, o Django cria a coluna
no banco com o nome rooms_id_id — bem confuso. O correto é nomear sem o _id:

# Você corrigindo ficaria assim
rooms = models.ForeignKey(...)
rooms_extras = models.ForeignKey(...)
condo = models.ForeignKey(...)

---

4. Rotas duplicadas e sintaxe errada

O id:pk/ não é reconhecido pelo Django — a sintaxe correta é <int:pk>/.
Além disso, com várias rotas idênticas o Django só vai bater na primeira e ignorar o resto.

Dá pra resolver juntando as 5 views em 2:

from django.urls import path
from . import views

urlpatterns = [
    path("properties/", views.PropertyListCreateView.as_view(), name="property-list"),
    path("properties/<int:pk>/", views.PropertyDetailView.as_view(), name="property-detail"),
]

E no views.py:

• Junta CreatePropertyView e ListAllPropertiesView herdando de generics.ListCreateAPIView
• Junta GetPropertyView, UpdatePropertyView e DeletePropertyView herdando de generics.RetrieveUpdateDestroyAPIView

---

5. IsPropertyOwner — ordem dos parâmetros errada

# Tá assim
def has_object_permission(self, obj, request, view):

# Mas o objetivo é que seja assim
def has_object_permission(self, request, view, obj):

---

6. signals.py — referências desatualizadas

Depois de renomear os campos ForeignKey (ponto 3), o signal fica:

# Desse jeito 
room = instance.rooms
if not room.properties.exists():
    room.delete()

---

7. Linha incompleta no serializer

# Vai quebrar na importação
images =

# Acredito que o que completaria seria isso
images = PropertiesPhotosSerializer(many=True, read_only=True, source="photos")

---

8. PropertiesPhotosSerializer — só tá incompleto msm

# Falta o self e ele não tá implementado
def get_url():
    pass

Não tenho certeza se vc vai implementar agora, mas comenta pra não dar erro.

---

[luisaferreirass]

1. Model sem dono

Estava esperando juntar com o CRUD dos usuários para poder fazer a adaptação

2. Serializers sem create() sobrescrito

Feito
Adicionei a seção e update também

3. Nomenclatura dos campos ForeignKey com _id

Feito
Não sabia que fazia isso automaticamente

4. Rotas duplicadas e sintaxe errada

Tive que criar diferentes serializer para o upload/leitura de imagens. Então, o update e o delete ficaram com serializers diferentes. Daria pra juntar, mas não acho que seja o ideal. Além disso, o GetPropertyView não necessita de autenticação, então, não vejo sentido em juntá-las. Um usuário deve poder ver um imóvel específico sem ser dono dele ou sem estar autenticado.

5. IsPropertyOwner — ordem dos parâmetros errada

Feito

6. signals.py — referências desatualizadas

Feito

7. Linha incompleta no serializer e 8. PropertiesPhotosSerializer — só tá incompleto msm

Feito (estava esperando me aprofundar na questão das imagens para poder fazer)

[DevlTz]

Salve Lulu.

---

Sobre o Ponto 1:

• Tá tranquilo, imaginei mesmo que vc tava esperarando o merge com o CRUD de usuários. O model de user parece tá corretinho, mas me avisa se vc precisar de ajuda pra juntar.

Sobre o Ponto 4:

• Esssa lógica tá 100% correta — GET público, Update/Delete protegido, e serializers diferentes pra imagens faz sentido. O único problema é que rotas repetidas no urls.py apontando pra views diferentes quebra o roteamento — o Django vai parar na primeira e as de baixo nunca são atingidas.

Dá pra manter toda essa lógica intacta e correta usando get_permissions() e get_serializer_class() numa view só:

from rest_framework import generics
from rest_framework.permissions import AllowAny, IsAuthenticated

class PropertyDetailView(generics.RetrieveUpdateDestroyAPIView):
    queryset = Properties.objects.all()

    def get_serializer_class(self):
        if self.request.method in ["PUT", "PATCH"]:
            return UpdatePropertySerializer
        return PropertiesSerializer

    def get_permissions(self):
        if self.request.method == "GET":
            return [AllowAny()]
        return [IsAuthenticated(), IsPropertyOwner()]

Seria uma coisa assim, mas nesse caso já mataria e serviria.

Assim o urls.py fica com uma rota só e a view decide sozinha qual serializer e permissão usar dependendo do método HTTP. Qualquer dúvida é só chamar!

• De resto, tá show :)