Różnice

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

--- pl:python:metawmodelach [2023/12/01 12:17] – [app_label] 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 =====
@@ Linia 24: / Linia 84: @@
 . **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.
+  * 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 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.