#django #drf #python #programowanie

Jestem w trakcie nauki Django Rest Framework i zastanawiam się, gdzie umieszczać logikę niezwiązaną z bazy danych, np wywołanie zewnetrznego API na podstawie przekazanego parametru do naszego API, wykonać jakieś operacje na plikach itp itd. plik models.py nie wydaję mi się odpowiednim miejscem. W innych frameworkach tj Symfony, Laravel wiadomo gdzie takie rzeczy wsadzać ale to są framworki typu MVC
  • 12
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

mam coś takiego,


@IamHater: to je bardzo dobre :O rzuciłem okiem na to co napisane jest o servicach (tego porzebuje op) i przyznam że pierwszy raz widze senior level guide do drfa/django/pythona.

na selektory sam wpadłem jakiś czas temu i nazywam je queries
  • Odpowiedz
Dwa pytanka do ekspertów: czy zastosowanie pola ManyToManyField jako listy użytkowników mających mieć pozwolenie na dostęp do tego obiektu jakieś zasadnicze wady?

robię sobie wtedy permission:

[...]
def hasobjectpermission(self, request,
  • 4
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@IamHater:
Użyj wbudowanych grup i permissionów
W permissionach bedziesz mial canview, cancomment, can_edit itd itp
W grupach - tester/owner/viewer

M2M się nie sprawdzi, bedzie ciezsze w utrzymaniu, nie potrzebujesz calego modelu uzytkownika, a permissiony sa natywnie wspierane przez django wiec po co kombinujesz
  • Odpowiedz
wiec po co kombinujesz jak kon pod góre


@Lunatik: Jakbym wiedział że to tak wygląda to bym w kunia się nie bawił ( ͡° ͜ʖ ͡°) Po prostu wyszedłem od custom permissions wykonywanych przez viewsety. Jeżeli DjangoModelPermissions będzie lepsze to się przyjrzę.

if user in obj.testers.all() or user in obj.owners.all() or user
  • Odpowiedz
#django #djangorestframework #drf #programowanie #python

mam coś takiego: zwykły model User z django.contrib.auth i model Profile, który ma usera jako ForeignKey
class Profile(models.Model):
    user = models.ForeignKey(User, related_name='profile')
    # ofc jakieś inne pola
  • 8
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@buntuubuntu: robisz tabele Day ktory ma jedno pole i to jeszcze datetime zamiast date. w profilu dales pole m2m do day przez drinkingday, troche bez sensu. tabela day nie powinna istniec, drinkingday powinien miec klucz obcy do User a Profil nie powinien miec pola days.

zalogowany uzytkownik powinien miec mozliwosc edycji tylko wlasnego profilu, jestes pewny, ze nie mozna edytowac czyjegos profilu? ;-)

zapytanie o profil ( w api) tez powinno uzywac user_id a nie id profilu bo to tylko wprowadza
  • Odpowiedz
1. Przy tworzeniu requirementsów możnaby napisać że to rozwiązanie tymczasowe, lecz dość ryzykowne ( ͡° ͜ʖ ͡°)
2. Serio nie rozumiem tendencji rozbijania uzytkownika na "uzytkownika" i "profil". Przecież Djagno oferuje mozliwosc używania wlasnego modelu to uwierzytelniania, dlaczego by nie skorzystać? Czemu ma służyć na struktura?
3. Sygnały to surprise driven development ( ͡° ͜ʖ ͡°)
4. Jeżeli piszesz po angielsku to użyj czegoś pokroju Grammarly do sprawdzenia pisowni, bo kilka rzeczy jest do poprawy gramatycznie
5. Masz błędy w syntaxie kodu "class UserViewSet(viewsets.Model# REST
  • Odpowiedz
Pytanie odnośnie REST API - nie wiem czy dobrze rozumiem
(moje REST API pisze w django rest frameworku)

Mam taka aplikacje gdzie model w basie danych ma relacje z częsciami samochodowymi ( wszystkie czesći muszą być powiązane tylko z jednym samochodem - to tylko przykład)
mam takie endpointy:

GET
  • 5
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach