Różnice

Różnice między wybraną wersją a wersją aktualną.

--- pl:python:metawmodelach [2023/12/01 11:54] – [base_manager_name] sindap
+++ pl:python:metawmodelach [2023/12/08 09:06] (aktualna) – [abstract] sindap
@@ Linia 2: / Linia 2: @@
 ===== abstract =====
+Opcja ''abstract'' w klasie ''Meta'' modelu Django służy do określenia, czy dany model ma być modelem abstrakcyjnym. Model abstrakcyjny to model, który nie ma związanej z nim tabeli w bazie danych i nie może być bezpośrednio używany do przechowywania danych. Zamiast tego, modele abstrakcyjne służą do dostarczania wspólnej funkcjonalności dla innych modeli poprzez dziedziczenie.
+Przykład użycia ''abstract'':
+<code python>
+from django.db import models
+class AbstractModel(models.Model):
+    common_field = models.CharField(max_length=100)
+    class Meta:
+        abstract = True
+class ConcreteModel(AbstractModel):
+    specific_field = models.IntegerField()
+</code>
+W tym przykładzie, ''AbstractModel'' jest modelem abstrakcyjnym ze wspólnym polem ''common_field''. Model ''ConcreteModel'' dziedziczy z ''AbstractModel'' i dodaje własne pole ''specific_field''. W wyniku tego, tylko ''ConcreteModel'' ma związaną tabelę w bazie danych, a ''AbstractModel'' nie.
+Główne zastosowania ''abstract'' to:
+. **Współdzielenie kodu:** Modele abstrakcyjne pozwalają na zdefiniowanie wspólnej funkcjonalności i pól, które można użyć w wielu modelach. Dzięki temu można unikać powtarzania kodu.
+. **Strukturyzacja kodu:** Działa jako narzędzie do organizacji kodu, gdy pewne właściwości lub metody są wspólne dla wielu modeli.
+Pamiętaj, że modele abstrakcyjne same w sobie nie tworzą tabel w bazie danych, więc nie są bezpośrednio używane do przechowywania danych. Są jedynie punktem wyjścia do dziedziczenia dla innych modeli, które mają związaną tabelę w bazie danych.
+Statystycznie najczęściej w takich modelach umieszczane są pola związane z zarządzaniem czasem, takie jak pola ''created_at'' (data utworzenia) i ''modified_at'' (data ostatniej modyfikacji). Ponadto, modele abstrakcyjne mogą zawierać inne wspólne pola, które mają sens dla wielu modeli w danym kontekście biznesowym.
+Przykłady pól, które mogą być umieszczane w modelu abstrakcyjnym:
+. **created_at:** Data utworzenia rekordu.\\
+. **modified_at:** Data ostatniej modyfikacji rekordu.\\
+. **created_by, modified_by:** Oznaczające użytkownika, który utworzył lub ostatnio zmodyfikował rekord.\\
+. **is_active:** Pole logiczne określające, czy rekord jest aktywny czy nie.\\
+. **description:** Pole tekstowe zawierające opis rekordu.\\
+. **slug:** Unikalny identyfikator tekstowy, często używany w adresach URL.\\
+Poniżej przykład takiego wpisu:
+<code python>
+from django.db import models
+from django.utils import timezone
+class BaseModel(models.Model):
+    created_at = models.DateTimeField(auto_now_add=True, verbose_name='Created At')
+    modified_at = models.DateTimeField(auto_now=True, verbose_name='Modified At')
+    class Meta:
+        abstract = True
+class YourModel1(BaseModel):
+    # Twoje pola dla modelu 1
+class YourModel2(BaseModel):
+    # Twoje pola dla modelu 2
+</code>
+Ostateczny wybór pól zależy od konkretnego przypadku użycia i wymagań biznesowych. Modele abstrakcyjne są używane w celu uniknięcia powtarzalności kodu i ułatwienia zarządzania wspólnymi właściwościami między wieloma modelami.
 ===== app_label =====
+Opcja ''app_label'' w klasie ''Meta'' modelu Django służy do określenia nazwy aplikacji, do której model należy. W Django, modele są zazwyczaj zdefiniowane w ramach aplikacji, a ''app_label'' pozwala na precyzyjne określenie, do której aplikacji model należy, szczególnie w przypadku, gdy model jest używany w kontekście wielu aplikacji.
+Przykład użycia ''app_label'':
+<code python>
+from django.db import models
+class MyModel(models.Model):
+    name = models.CharField(max_length=100)
+    class Meta:
+        app_label = 'myapp'
+</code>
+W powyższym przykładzie, ''app_label = `myapp`'' oznacza, że model ''MyModel'' należy do aplikacji o nazwie ''myapp''.
+Główne zastosowania ''app_label'' to:
+. **Rozstrzyganie konfliktów nazw:**
+  * Jeśli w różnych aplikacjach masz modele o tej samej nazwie, możesz użyć ''app_label'', aby jednoznacznie określić, do której aplikacji dany model należy.
+. **Wielokrotne zastosowanie tego samego modelu:**
+  * W przypadku, gdy ten sam model jest używany w ramach wielu aplikacji, ''app_label'' pozwala na jednoznaczne określenie przynależności modelu do konkretnej aplikacji.
+W większości przypadków, nie musisz ręcznie ustawiać ''app_label'', ponieważ Django automatycznie przypisuje modele do aplikacji, w której są zdefiniowane. Jednakże, w sytuacjach, gdzie modele są używane w wielu aplikacjach o tej samej nazwie, można skorzystać z ''app_label'', aby uniknąć potencjalnych konfliktów.
 ===== base_manager_name =====
@@ Linia 21: / Linia 106: @@
 </code>
-W powyższym przykładzie, ''base_manager_name = 'custom_manager''' oznacza, że menedżer podstawowy dla modelu ''MyModel'' będzie miał niestandardową nazwę ''custom_manager'' zamiast domyślnej nazwy ''objects''.
+W powyższym przykładzie, ''base_manager_name = `custom_manager`'' oznacza, że menedżer podstawowy dla modelu ''MyModel'' będzie miał niestandardową nazwę ''custom_manager'' zamiast domyślnej nazwy ''objects''.
 Ustawianie ''base_manager_name'' może być użyteczne w przypadkach, gdy chcesz dostosować nazwę menedżera podstawowego dla modelu do czegoś bardziej znaczącego w kontekście Twojej aplikacji lub projektu. Jest to szczególnie przydatne, gdy masz kilka menedżerów dla danego modelu i chcesz jednoznacznie określić, który z nich jest traktowany jako menedżer podstawowy.
@@ Linia 162: / Linia 247: @@
 Należy zauważyć, że jeśli nie używasz ''default_related_name'', Django i tak wygeneruje automatyczną nazwę relacji wstecznej na podstawie nazwy modelu, ale używając tej opcji, możesz dostosować tę nazwę do swoich preferencji.
+==== Różnice między base_manager_name i default_manager_name ====
+Opcje ''base_manager_name'' i ''default_manager_name'' w klasie ''Meta'' modelu Django różnią się w swoim zastosowaniu i znaczeniu:
+. **base_manager_name:** Określa nazwę menedżera podstawowego (base manager) dla modelu. Menedżer podstawowy jest używany do operacji na obiektach modelu, takich jak ''MyModel.objects.all()''. Opcja ta wpływa na menedżera, który jest używany do operacji na całym zbiorze obiektów danego modelu.
+Przykład użycia ''base_manager_name'':
+<code python>
+from django.db import models
+class MyModel(models.Model):
+    name = models.CharField(max_length=100)
+    class Meta:
+        base_manager_name = 'custom_manager'
+</code>
+W tym przypadku, ''custom_manager'' będzie menedżerem podstawowym dla modelu ''MyModel''.
+. **default_manager_name:** Określa nazwę domyślnego menedżera dla modelu. Domyślny menedżer jest używany do operacji na obiektach modelu, gdy menedżer nie jest specjalnie określony w zapytaniu. To wpływa na menedżera, który jest używany, gdy używamy modelu bezpośrednio, na przykład ''MyModel.objects.all()''.
+Przykład użycia ''default_manager_name'':
+<code python>
+from django.db import models
+class MyModel(models.Model):
+    name = models.CharField(max_length=100)
+    class Meta:
+        default_manager_name = 'custom_manager'
+</code>
+W tym przypadku, ''custom_manager'' będzie domyślnym menedżerem dla modelu ''MyModel''.
+Podsumowując, ''base_manager_name'' wpływa na menedżera używanego do operacji na całym zbiorze obiektów modelu, podczas gdy ''default_manager_name'' wpływa na menedżera używanego do operacji na obiektach modelu w przypadku użycia modelu bezpośrednio. Oba ustawienia pozwalają na niestandardowe nazwanie menedżerów w kontekście danego modelu.
 ===== get_latest_by =====