Różnice

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

--- pl:python:metawmodelach [2023/12/01 12:07] – [default_related_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 169: / Linia 254: @@
 . **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`:
+Przykład użycia ''base_manager_name'':
-    ```python
+<code python>
-    from django.db import models
+from django.db import models
-    class MyModel(models.Model):
+class MyModel(models.Model):
-        name = models.CharField(max_length=100)
+    name = models.CharField(max_length=100)
-        class Meta:
+    class Meta:
-            base_manager_name = 'custom_manager'
+        base_manager_name = 'custom_manager'
-    ```
+</code>
-    W tym przypadku, `custom_manager` będzie menedżerem podstawowym dla modelu `MyModel`.
+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()`.
+. **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`:
+Przykład użycia ''default_manager_name'':
-    ```python
+<code python>
-    from django.db import models
+from django.db import models
-    class MyModel(models.Model):
+class MyModel(models.Model):
-        name = models.CharField(max_length=100)
+    name = models.CharField(max_length=100)
-        class Meta:
+    class Meta:
-            default_manager_name = 'custom_manager'
+        default_manager_name = 'custom_manager'
-    ```
+</code>
-    W tym przypadku, `custom_manager` będzie domyślnym menedżerem dla modelu `MyModel`.
+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.
+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 =====