====== Opcje Meta w modelach ======

===== 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:

1. **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.

2. **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:

1. **created_at:** Data utworzenia rekordu.\\
2. **modified_at:** Data ostatniej modyfikacji rekordu.\\
3. **created_by, modified_by:** Oznaczające użytkownika, który utworzył lub ostatnio zmodyfikował rekord.\\
4. **is_active:** Pole logiczne określające, czy rekord jest aktywny czy nie.\\
5. **description:** Pole tekstowe zawierające opis rekordu.\\
6. **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:

1. **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.
2. **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 =====

Opcja ''base_manager_name'' w klasie ''Meta'' modelu Django pozwala na określenie niestandardowej nazwy menedżera, który jest uznawany za "menedżera podstawowego" (base manager) dla danego modelu. Menedżer podstawowy to menedżer, który jest używany do operacji na obiektach modelu, takich jak ''MyModel.objects.all()''.

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 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.

Warto jednak pamiętać, że ''base_manager_name'' to opcja bardziej zaawansowana i zazwyczaj nie jest konieczne jej ustawianie w większości przypadków. Django domyślnie używa menedżera o nazwie ''objects'' jako menedżera podstawowego.

===== db_table =====

Opcja ''db_table'' w klasie `Meta` modelu Django pozwala na określenie niestandardowej nazwy tabeli w bazie danych, do której model powinien się odnosić. Domyślnie, Django automatycznie generuje nazwę tabeli na podstawie nazwy modelu, ale używając `db_table`, możesz dostosować tę nazwę.

Przykład użycia ''db_table'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        db_table = 'custom_table_name'
</code>

W powyższym przykładzie, ''db_table = 'custom_table_name''' oznacza, że tabela odpowiadająca modelowi ''MyModel'' będzie miała niestandardową nazwę ''custom_table_name'' zamiast domyślnej nazwy generowanej przez Django.

Ustawienie ''db_table'' może być przydatne w różnych sytuacjach, takich jak:

1. **Integracja z istniejącą bazą danych:** Jeśli używasz modelu Django do łączenia się z istniejącą już bazą danych, możesz dostosować nazwę tabeli, aby pasowała do istniejącej struktury.

2. **Zachowanie konwencji nazewniczych:** Jeśli projekt stosuje konkretne konwencje nazewnicze dla tabel, możesz użyć ''db_table'', aby dostosować nazwę tabeli do tych konwencji.

3. **Unikanie konfliktów z nazwami istniejących tabel:** W większych projektach, w których może być wiele modeli, które przekształcą się w tabelę, możesz chcieć uniknąć konfliktów nazw tabel, zwłaszcza jeśli modele są w różnych aplikacjach.

Warto jednak pamiętać, że zazwyczaj nie jest konieczne ustawianie ''db_table'', a Django domyślnie generuje odpowiednie nazwy tabeli na podstawie nazwy modelu. Ustawienie to może być przydatne głównie w przypadku specjalnych przypadków, takich jak integracja z istniejącą bazą danych.

=====     Table names =====

==== db_table_comment ====

Opcja ''db_table_comment'' w klasie ''Meta'' modelu Django pozwala określić komentarz dla tabeli w bazie danych. Komentarze do tabel są informacyjnymi komunikatami, które mogą zawierać dodatkowe informacje o celu lub funkcji danej tabeli.

Przykład użycia ''db_table_comment'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        db_table_comment = 'This table stores information about MyModel.'
</code>

W powyższym przykładzie, ''db_table_comment = `This table stores information about MyModel`''. oznacza, że tabela odpowiadająca modelowi ''MyModel'' będzie miała komentarz mówiący, że przechowuje informacje o ''MyModel''.

Ustawianie komentarzy do tabel może być przydatne w przypadku, gdy chcesz dokumentować lub udokumentować cel danej tabeli w bazie danych. Te komentarze mogą być również używane jako pomoc dla innych osób pracujących nad projektem, zwłaszcza w przypadku większych zespołów programistycznych.

Warto jednak zauważyć, że obsługa komentarzy do tabel w bazie danych zależy od używanej bazy danych. Nie wszystkie bazy danych obsługują tę funkcjonalność, więc warto sprawdzić dokumentację konkretnej bazy, której używasz. W przykładzie wyżej, obsługa komentarzy do tabel jest dostępna w niektórych bazach danych, takich jak PostgreSQL.
===== db_tablespace =====

Opcja ''db_tablespace'' w klasie ''Meta'' modelu Django pozwala określić przestrzeń tabelową (tablespace) dla danej tabeli w bazie danych. Przestrzeń tabelową można rozumieć jako obszar w bazie danych, który jest używany do przechowywania danych dla danej tabeli.

Przykład użycia ''db_tablespace'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        db_tablespace = 'custom_tablespace'
</code>

W powyższym przykładzie, ''db_tablespace = 'custom_tablespace''' oznacza, że tabela odpowiadająca modelowi ''MyModel'' będzie przechowywana w przestrzeni tabelowej o nazwie ''custom_tablespace''.

Ustawianie ''db_tablespace'' może być użyteczne, gdy masz potrzebę kontrolowania, w jakiej przestrzeni tabelowej są przechowywane dane dla konkretnego modelu. Przestrzenie tabelowe mogą być używane w celu optymalizacji przechowywania danych w bazie danych.

Warto jednak pamiętać, że nie wszystkie bazy danych obsługują przestrzenie tabelowe, a ich dostępność zależy od używanej bazy danych. Opcja ''db_tablespace'' może być bardziej istotna w przypadku korzystania z baz danych, które oferują taką funkcjonalność, na przykład PostgreSQL.

Jeśli nie masz szczególnych wymagań co do przestrzeni tabelowej, zazwyczaj można pominąć ustawianie tej opcji, a Django automatycznie użyje domyślnej przestrzeni tabelowej dla danej bazy danych.
===== default_manager_name =====

Opcja ''default_manager_name'' w klasie ''Meta'' modelu Django pozwala określić nazwę, pod którą będzie dostępny domyślny menedżer (manager) modelu. Menedżer to obiekt, który dostarcza interfejs do przeprowadzania zapytań w bazie danych dla danego modelu.

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 powyższym przykładzie, ''default_manager_name = 'custom_manager''' oznacza, że dostęp do domyślnego menedżera dla modelu ''MyModel'' będzie dostępny pod nazwą ''custom_manager''. 

Domyślnie, jeśli nie używasz opcji ''default_manager_name'', menedżer jest dostępny pod nazwą ''objects''. Na przykład:

<code python>
my_model_instance = MyModel.objects.all()
</code>

Jeśli jednak użyjesz ''default_manager_name'', musisz korzystać z tej niestandardowej nazwy menedżera. W naszym przykładzie:

<code python>
my_model_instance = MyModel.custom_manager.all()
</code>

Używanie opcji ''default_manager_name'' jest przydatne w sytuacjach, gdzie chcesz dostosować nazwę domyślnego menedżera do czegoś bardziej znaczącego w kontekście Twojego modelu. Warto jednak pamiętać, że jeśli zmienisz tę nazwę, musisz pamiętać o jej użyciu w kodzie wszędzie tam, gdzie korzystasz z menedżera.

===== default_related_name =====

Opcja ''default_related_name'' w klasie ''Meta'' modelu Django pozwala określić domyślną nazwę relacji wstecznej (reverse relation) związaną z danym modelem. Relacja wsteczna to relacja, którą uzyskujesz poprzez użycie atrybutu, który nie istnieje w modelu, ale jest automatycznie generowany przez Django.

Przykład użycia ''default_related_name'':

<code python>
from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

    class Meta:
        default_related_name = 'books'
</code>

W powyższym przykładzie, ''default_related_name = 'books''' oznacza, że relacja wsteczna z modelu ''Author'' do modelu ''Book'' będzie miała domyślną nazwę ''books''. Możesz teraz uzyskać dostęp do książek napisanych przez danego autora za pomocą tej nazwy relacji wstecznej:

<code python>
author_instance.books.all()
</code>

Domyślnie Django automatycznie generuje nazwę relacji wstecznej w oparciu o nazwę modelu, ale ''default_related_name'' pozwala na dostosowanie tej nazwy. Jest to przydatne zwłaszcza w przypadku, gdy istnieje więcej niż jedna relacja wsteczna związana z danym modelem.

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:

1. **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''.

2. **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 =====

Opcja ''get_latest_by'' w klasie `Meta` modelu Django pozwala określić pole, które zostanie użyte do określenia najnowszego (najbardziej aktualnego) rekordu w modelu. W skrócie, pozwala to na łatwe uzyskanie najnowszego obiektu modelu na podstawie określonego pola.\\
\\
Przykład użycia ''get_latest_by'':

<code python>
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    pub_date = models.DateTimeField()
    
    class Meta:
        get_latest_by = 'pub_date'
</code>

W powyższym przykładzie, ''get_latest_by = 'pub_date''' oznacza, że Django będzie używać pola ''pub_date'' do określenia najnowszego artykułu w modelu ''Article''. Dzięki temu, można łatwo uzyskać najnowszy artykuł za pomocą metody ''latest()'':

<code python>
latest_article = Article.objects.latest()
</code>

Django zwróci obiekt ''Article'', który ma najnowszą datę publikacji ''(`pub_date`)''.

Opcja ''get_latest_by'' jest szczególnie przydatna, gdy pracujesz z danymi, w których ważne jest śledzenie daty lub czasu i chcesz szybko uzyskać najnowszy obiekt z danego modelu. Warto jednak pamiętać, że nie jest to jedyny sposób na uzyskanie najnowszego obiektu, a ''get_latest_by'' po prostu ułatwia to w niektórych przypadkach.

===== managed =====

Opcja ''managed'' w klasie ''Meta'' modelu Django informuje Django, czy ma automatycznie zarządzać tabelą w bazie danych dla tego modelu. Domyślnie, wartość ''managed'' wynosi ''True'', co oznacza, że Django będzie automatycznie tworzyć, aktualizować i usuwać tabelę w bazie danych zgodnie z definicją modelu. Jeśli ustawisz ''managed'' na ''False'', oznacza to, że sam będziesz zarządzać tabelą, a Django nie będzie tworzyć ani aktualizować jej automatycznie.\\
\\
Przykład użycia opcji ''managed'':

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)
    age = models.IntegerField()

    class Meta:
        managed = False
        db_table = 'custom_table_name'
</code>

W powyższym przykładzie:\\

  * ''managed = False'' oznacza, że Django nie będzie automatycznie zarządzać tabelą w bazie danych dla modelu ''MyModel''.
  * ''db_table = 'custom_table_name''' pozwala określić niestandardową nazwę tabeli, jeśli ''managed'' jest ustawione na `False`.

Ustawienie ''managed'' na ''False'' jest przydatne w sytuacjach, gdy tabela już istnieje w bazie danych i nie chcesz, aby Django próbowało ją modyfikować. To również przydatne w przypadku, gdy korzystasz z wielu źródeł danych i chcesz ręcznie zarządzać schematem tabeli dla danego modelu.\\
\\
Warto zauważyć, że ustawienie ''managed'' na ''False'' oznacza, że będziesz odpowiedzialny za utrzymanie zgodności schematu tabeli z modelem. Jeśli dokonasz zmian w modelu, które wpływają na schemat tabeli, będziesz musiał samodzielnie zaktualizować tabelę w bazie danych.
===== order_with_respect_to =====

Opcja ''order_with_respect_to'' w klasie ''Meta'' modelu Django była dostępna w starszych wersjach Django (przed wersją 1.9), ale została zdeprecjonowana i ostatecznie usunięta. W związku z tym, jej stosowanie nie jest zalecane, a jej funkcjonalność została zastąpiona przez bardziej elastyczny mechanizm, tj. ''Meta.ordering''.\\
\\
Opcja ''order_with_respect_to'' była używana do określania, które pola w modelu są używane do ustalania kolejności dla obiektów w relacji wiele-do-wielu. Na przykład, jeśli mieliśmy modele ''Author'' i ''Book'', a ''Book'' było w relacji wiele-do-wielu z ''Author'', to ''order_with_respect_to'' pozwalałoby nam na określenie, które pole w ''Book'' powinno być używane do sortowania książek w kontekście danego autora.\\
\\
Przykład (na potrzeby ilustracji, ponieważ opcja jest zdeprecjonowana):

<code python>
class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    
    class Meta:
        order_with_respect_to = 'author'
</code>

Jednak, zamiast ''order_with_respect_to'', obecnie zaleca się używanie opcji ''ordering'' w klasie ''Meta'' modelu, co daje bardziej ogólną kontrolę nad kolejnością sortowania. Przykład z użyciem ''ordering'':

<code python>
class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)
    
    class Meta:
        ordering = ['author', 'title']
</code>

W tym przypadku, książki zostaną posortowane najpierw według autora, a następnie według tytułu. Jeśli ''order_with_respect_to'' było używane, to pole sortujące było by definiowane tylko dla danego modelu, co ograniczało elastyczność sortowania w różnych kontekstach.
===== ordering =====

Opcja ''ordering'' w klasie ''Meta'' modelu Django jest używana do określenia domyślnego porządku sortowania rekordów, gdy zapytanie o dane z tego modelu jest wykonywane. Ustawienie tej opcji pozwala na kontrolowanie, w jakiej kolejności rekordy są zwracane, gdy nie jest wyraźnie określone inne kryterium sortowania.\\
\\
Przykład użycia ''ordering'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    date_created = models.DateTimeField(auto_now_add=True)

    class Meta:
        ordering = ['-date_created']
</code>

W tym przykładzie, opcja ''ordering'' została użyta do określenia, że domyślnym porządkiem sortowania dla rekordów ''MyModel'' jest malejąca kolejność według pola ''date_created''. Znak minus (''-'') przed poliem oznacza sortowanie malejące.\\
\\
Gdy zapytanie o dane z modelu ''MyModel'' nie zawiera wyraźnego kryterium sortowania, rekordy zostaną zwrócone zgodnie z ustalonym w opcji ''ordering'' porządkiem.

<code python>
# Przykład zapytania o dane z modelu z uwzględnieniem domyślnego porządku sortowania
my_model_objects = MyModel.objects.all()

# Rekordy zostaną zwrócone w kolejności malejącej według daty utworzenia
</code>

Opcja ''ordering'' może zawierać jedno lub więcej pól, a każde pole może być poprzedzone znakiem minus, co oznacza sortowanie malejące. Jeśli pole nie jest poprzedzone znakiem minus, domyślnie jest to sortowanie rosnące.

<code python>
class AnotherModel(models.Model):
    name = models.CharField(max_length=100)
    quantity = models.IntegerField()
    price = models.DecimalField(max_digits=5, decimal_places=2)

    class Meta:
        ordering = ['name', '-quantity', 'price']
</code>

W tym przykładzie, rekordy modelu ''AnotherModel'' zostaną zwrócone w kolejności rosnącej według pola ''name'', a następnie w kolejności malejącej według pola ''quantity'', a na końcu w kolejności rosnącej według pola ''price''.
===== permissions =====

Opcja ''permissions'' w klasie ''Meta'' modelu Django jest używana do ręcznego definiowania zestawu uprawnień (permissions), które są przypisane do tego modelu. Umożliwia to precyzyjną kontrolę nad uprawnieniami, które są dostępne dla danego modelu.\\
\\
Przykład użycia ''permissions'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        permissions = [
            ("can_view_details", "Can view details of objects"),
            ("can_edit_details", "Can edit details of objects"),
        ]
</code>

W tym przykładzie, model ''MyModel'' został dostosowany do zawierania dwóch niestandardowych uprawnień: ''"can_view_details"'' (może przeglądać szczegóły obiektów) i ''"can_edit_details"'' (może edytować szczegóły obiektów).\\
\\
Uprawnienia zdefiniowane za pomocą ''permissions'' mogą być później używane w kodzie aplikacji do sprawdzania, czy użytkownik ma dostęp do określonych operacji. Na przykład:

<code python>
if request.user.has_perm('app_name.can_view_details'):
    # Wykonaj pewne operacje dostępne tylko dla użytkowników z uprawnieniem 'can_view_details'
    pass
</code>

Użycie ''permissions'' jest szczególnie przydatne, gdy chcemy zdefiniować niestandardowe uprawnienia, które nie są dostarczane domyślnie przez Django, ale są związane z naszym modelem. Umożliwia to bardziej elastyczną kontrolę nad dostępem do różnych funkcji w naszej aplikacji.

===== default_permissions =====

Opcja ''default_permissions'' w klasie ''Meta'' modelu Django jest używana do kontrolowania domyślnego zestawu uprawnień (permissions), które są przypisywane do tego modelu. Upewnienie się, że model ma odpowiednie uprawnienia jest istotne, gdy korzystamy z systemu autoryzacji Django.\\
\\
Domyślnie, Django nadaje pewne podstawowe uprawnienia każdemu modelowi. Te podstawowe uprawnienia obejmują:\\

  * ''add'': Pozwala na dodawanie nowych obiektów modelu.
  * ''change'': Pozwala na edytowanie istniejących obiektów modelu.
  * ''delete'': Pozwala na usuwanie istniejących obiektów modelu.
  * ''view'': Pozwala na przeglądanie istniejących obiektów modelu.

Ustawienie ''default_permissions'' pozwala na dostosowanie, które z tych podstawowych uprawnień są przypisywane do modelu. Można również dostosować to, czy te uprawnienia są przypisywane do roli administracyjnej.\\
\\
Przykład użycia ''default_permissions'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        default_permissions = ('add', 'change')  # Tylko dodawanie i edytowanie
</code>

W tym przykładzie, model ''MyModel'' będzie miał tylko uprawnienia do dodawania (''add'') i edytowania (''change''). Uprawnienia do usuwania (''delete'') i przeglądania (''view'') nie będą przypisane domyślnie.\\
\\
Opcja ''default_permissions'' jest szczególnie użyteczna, gdy tworzymy modele, które nie wymagają pełnego zestawu uprawnień, lub gdy chcemy bardziej precyzyjnie kontrolować, jakie uprawnienia są dostępne dla danego modelu.

===== proxy =====

Opcja ''proxy'' w klasie ''Meta'' modelu Django jest używana do określenia, czy dany model jest modelem proxy. Model proxy to model, który reprezentuje tę samą tabelę bazodanową co inny model, ale nie tworzy nowej tabeli. Zamiast tego, używa tabeli istniejącej już w bazie danych, co umożliwia korzystanie z tych samych danych, ale na przykład z dodatkowymi metodami czy polami.\\
\\
Przykład użycia ''proxy'':

<code python>
from django.db import models

class MyBaseModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        abstract = True

class MyModel(MyBaseModel):
    description = models.TextField()

class MyModelProxy(MyBaseModel):
    class Meta:
        proxy = True
</code>

W tym przykładzie, ''MyModelProxy'' jest modelem proxy, który korzysta z tabeli, do której przyczepiony jest ''MyBaseModel''. Nie tworzy on nowej tabeli, ale umożliwia dodanie nowych metod, pól lub innych modyfikacji do tego modelu bez wpływania na strukturę istniejącej tabeli ''MyBaseModel''.\\
\\
Modele proxy są użyteczne w sytuacjach, gdzie chcemy dodać nowe funkcje do istniejącego modelu, ale nie chcemy tworzyć nowej tabeli w bazie danych. Opcja `proxy` pozwala na utworzenie modelu, który dziedziczy z istniejącego modelu, ale może dodawać lub modyfikować pewne elementy bez konieczności tworzenia nowej tabeli.

<code python>
# Przykład użycia modelu proxy w widoku Django
proxy_instance = MyModelProxy.objects.get(pk=1)
proxy_instance.new_method()  # Nowa metoda dostępna tylko w modelu proxy
</code>

Warto zauważyć, że modele proxy są zazwyczaj używane w połączeniu z dziedziczeniem modelu ''(`abstract=True` lub dziedziczenie bezpośrednie)'', ale opcja ''proxy'' umożliwia bardziej wyraźne oznaczenie, że model jest modelem proxy.

===== required_db_features =====

Opcja ''required_db_features'' w klasie ''Meta'' modelu Django została wprowadzona w Django 4.2 w celu umożliwienia określenia funkcji specyficznych dla bazy danych, które są wymagane do obsługi danego modelu. Jest to używane w przypadkach, gdy dany model korzysta z funkcji specyficznych dla danej bazy danych i aplikacja chce jawnie określić, jakie funkcje są wymagane.\\
\\
Przykład użycia ''required_db_features'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        required_db_features = {'supports_subqueries', 'supports_index_on_text_field'}
</code>

W tym przykładzie, opcja ''required_db_features'' została użyta do określenia, że model ten wymaga, aby baza danych obsługująca ten model miała funkcje związane z obsługą subzapytań ''(`supports_subqueries`)'' i wsparciem dla indeksów na polach tekstowych ''(`supports_index_on_text_field`)''.\\
\\
Jeśli aplikacja próbuje używać tego modelu w środowisku, gdzie baza danych nie obsługuje tych konkretnych funkcji, może to prowadzić do błędów lub zachowań niezgodnych z oczekiwaniami.\\
\\
Opcja ''required_db_features'' pomaga zabezpieczyć aplikację przed przypadkowym użyciem modelu w środowisku, które nie obsługuje konkretnych funkcji wymaganych przez ten model.

===== required_db_vendor =====

Opcja ''required_db_vendor'' w klasie `Meta` modelu Django została wprowadzona w Django 4.1 w celu umożliwienia określenia, który dostawca baz danych (database vendor) jest wymagany do obsługi danego modelu. Jest to używane w przypadkach, gdy dany model korzysta z funkcji specyficznych dla danego dostawcy bazy danych.\\
\\
Przykład użycia ''required_db_vendor'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        required_db_vendor = 'mysql'
</code>

W tym przykładzie, opcja ''required_db_vendor'' została ustawiona na ''mysql'', co oznacza, że model ten wymaga, aby baza danych obsługująca ten model była dostawcą MySQL. Jeśli aplikacja próbuje używać tego modelu w środowisku, gdzie baza danych nie jest dostawcą MySQL, może to prowadzić do błędów.\\
\\
Przydatne jest to zwłaszcza w przypadku, gdy korzystamy z funkcji specyficznych dla danego dostawcy bazy danych, które nie są przenośne pomiędzy różnymi bazami danych obsługiwanymi przez Django.

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        required_db_vendor = 'sqlite'
</code>

W powyższym przykładzie, model ten zostałby uznany za wymagający dostawcy SQLite, co oznaczałoby, że funkcje specyficzne dla SQLite powinny być obsługiwane przez bazę danych podczas używania tego modelu.\\
\\
Opcja ''required_db_vendor'' pomaga zabezpieczyć aplikację przed przypadkowym użyciem modelu w nieobsługiwanym środowisku bazy danych.

===== select_on_save =====

Opcja ''select_on_save'' w klasie ''Meta'' modelu Django została wprowadzona w Django 4.1 w celu umożliwienia kontrolowania zachowania zapytań SELECT podczas zapisywania nowych obiektów modelu.\\
\\
Głównym celem tej opcji jest zminimalizowanie liczby zapytań SELECT w przypadku, gdy tworzony jest nowy obiekt modelu i wiele pól tego obiektu jest ustawiane na wartości domyślne.\\
\\
Przykład użycia ''select_on_save'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100, default="Default Name")
    category = models.CharField(max_length=50, default="Default Category")

    class Meta:
        select_on_save = True
</code>

W tym przykładzie, gdy tworzony jest nowy obiekt ''MyModel'', a pola ''name'' i ''category'' mają wartości domyślne, to opcja ''select_on_save'' sprawia, że nie zostaną wykonane dodatkowe zapytania SELECT w celu pobrania danych z bazy danych. Zamiast tego, obiekt zostanie zapisany bez wcześniejszego pobierania wartości domyślnych z bazy danych.\\
\\
Opcja ta może być szczególnie użyteczna w przypadku, gdy tworzymy wiele obiektów modelu z wartościami domyślnymi i chcemy uniknąć zbędnych zapytań SELECT.

===== indexes =====

Opcja ''indexes'' w klasie ''Meta'' modelu Django jest używana do definiowania indeksów dla pól w tabeli bazodanowej reprezentowanej przez dany model. Indeksy przyspieszają wyszukiwanie i sortowanie danych w bazie danych.\\
\\
Przykład użycia ''indexes'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    category = models.CharField(max_length=50)

    class Meta:
        indexes = [
            models.Index(fields=['name', 'category']),
        ]
</code>

W tym przykładzie, opcja ''indexes'' została użyta do zdefiniowania indeksu dla kombinacji pól ''name'' i ''category''. Indeks ten przyspieszy zapytania, które używają tych pól w klauzuli ''WHERE'' lub ''ORDER BY''.\\
\\
Można również zastosować ''unique=True'' dla indeksu, aby sprawić, że kombinacja wartości w tych polach będzie unikalna:

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)
    category = models.CharField(max_length=50)

    class Meta:
        indexes = [
            models.Index(fields=['name', 'category'], unique=True),
        ]
</code>

Alternatywnie, można używać opcji ''unique'' bezpośrednio na polach modelu do uzyskania tego samego efektu:

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100, unique=True)
    category = models.CharField(max_length=50)
</code>

W przypadku indeksów, warto pamiętać, że nadmierne ich używanie może wpłynąć na wydajność operacji zapisu (INSERT, UPDATE, DELETE), więc należy dostosować strategię indeksacji do konkretnych wymagań aplikacji. Opcja ''indexes'' pozwala na bardziej zaawansowane dostosowywanie indeksów niż opcja ''index_together'', ponieważ można definiować różne typy indeksów (np. indeks unikalny, indeks full-text) i dodawać bardziej zaawansowane opcje.

===== unique_together =====

Opcja ''unique_together'' w klasie ''Meta'' modelu Django jest używana do definiowania warunku, który wymaga, aby kombinacja określonych pól w tabeli była unikalna. Oznacza to, że nie może istnieć więcej niż jeden rekord z taką samą kombinacją wartości w określonych polach.\\
\\
Przykład użycia ''unique_together'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    category = models.CharField(max_length=50)

    class Meta:
        unique_together = [
            ['name', 'category'],
        ]
</code>

W tym przykładzie, opcja ''unique_together'' została użyta do zdefiniowania warunku, który wymusza unikalność kombinacji pól ''name'' i ''category'' w tabeli. Innymi słowy, nie może istnieć dwa rekordy z tymi samymi wartościami ''name'' i ''category''.\\
\\
Można również użyć ''unique_together'' z użyciem tupli zamiast listy:\\

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)
    category = models.CharField(max_length=50)

    class Meta:
        unique_together = ('name', 'category')
</code>

Warto zauważyć, że unikalność jest sprawdzana tylko dla tych rekordów, które są faktycznie zapisywane w bazie danych. Dla rekordów, które są tylko tymczasowo obecne w pamięci, nie jest sprawdzane, czy są unikalne. Oznacza to, że przed zapisaniem nowego rekordu, aplikacja powinna sprawdzić, czy nie narusza ona warunku ''unique_together'', co może być osiągnięte poprzez odpowiednie zapytania do bazy danych lub walidacje w formularzach.\\
\\
Opcja ''unique_together'' jest przydatna w sytuacjach, gdzie pewne kombinacje pól powinny być unikalne, ale same pola nie muszą być unikalne.

===== index_together =====

Opcja ''index_together'' w klasie ''Meta'' modelu Django jest używana do definiowania wspólnego zestawu pól, dla których zostaną utworzone indeksy w bazie danych. Indeksy przyspieszają wyszukiwanie i sortowanie danych w bazie danych.\\
\\
Przykład użycia ''index_together'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    category = models.CharField(max_length=50)

    class Meta:
        index_together = [
            ['name', 'category'],
        ]
</code>

W tym przykładzie, opcja ''index_together'' została użyta do zdefiniowania indeksu dla kombinacji pól ''name'' i ''category''. Indeks ten przyspieszy zapytania, które używają tych pól w klauzuli ''WHERE'' lub ''ORDER BY''.\\
\\
Alternatywnie, można użyć ''indexes'' dla pojedynczych pól lub ''models.Index'' dla bardziej zaawansowanych opcji indeksów. Przykład z użyciem ''indexes'':

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)
    category = models.CharField(max_length=50)

    class Meta:
        indexes = [
            models.Index(fields=['name', 'category']),
        ]
</code>

W przypadku, gdy indeks obejmuje tylko jedno pole, można użyć bezpośrednio ''models.Index''. Jednak jeśli planujesz indeksować kombinacje pól, ''index_together'' może być bardziej czytelne i zwięzłe.\\
\\
Warto jednak pamiętać, że nadmierny użytek indeksów może wpłynąć na wydajność operacji zapisu (INSERT, UPDATE, DELETE), więc należy dostosować strategię indeksacji do konkretnej sytuacji aplikacji.

===== constraints =====

Opcja ''constraints'' w klasie ''Meta'' modelu Django jest używana do definiowania niestandardowych ograniczeń (constraints) dla tabeli bazodanowej reprezentowanej przez dany model. Ograniczenia te obejmują takie elementy jak klucze obce, unikalność, sprawdzanie warunków itp.\\
\\
Przykład użycia ''constraints'':

<code python>
from django.db import models

class MyModel(models.Model):
    name = models.CharField(max_length=100)
    category = models.ForeignKey('Category', on_delete=models.CASCADE)

    class Meta:
        constraints = [
            models.UniqueConstraint(fields=['name', 'category'], name='unique_name_in_category')
        ]
</code>

W tym przykładzie, opcja ''constraints'' została użyta do zdefiniowania niestandardowego ograniczenia unikalności ''(`UniqueConstraint`)''. Ograniczenie to sprawdza, czy kombinacja pól ''name'' i ''category'' w tabeli jest unikalna.\\
\\
Inne przykłady ograniczeń, które można zdefiniować za pomocą tej opcji, to np. klucze obce (`ForeignKey`), sprawdzanie warunków ''(`CheckConstraint`)'', klucze główne ''(`Primarykey`)'' itp. Ograniczenia te pozwalają na bardziej zaawansowane zarządzanie strukturą danych w bazie danych, przekraczając podstawowe relacje i indeksy.\\
\\
Dokładny sposób definiowania i konfigurowania niestandardowych ograniczeń różni się w zależności od rodzaju ograniczenia. Szczegóły dotyczące dostępnych opcji i konfiguracji można znaleźć w oficjalnej dokumentacji Django dotyczącej [[https://docs.djangoproject.com/en/stable/ref/models/constraints/|Niestandardowych ograniczeń (Constraints)]].

===== verbose_name =====

Opcja ''verbose_name'' w klasie ''Meta'' modelu Django jest używana do określenia czytelnej dla człowieka nazwy dla pojedynczego obiektu danego modelu. Jest to szczególnie użyteczne w kontekście interfejsu administracyjnego Django (Django admin) oraz innych miejsc, gdzie prezentowane są dane z modelu w formie tekstowej.\\
\\
Przykład użycia ''verbose_name'':\\

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        verbose_name = "My Custom Model"
</code>

Domyślnie Django automatycznie generuje nazwę na podstawie nazwy modelu. Na przykład, jeśli model ma nazwę ''"MyModel"'', Django automatycznie generuje ''"My model"'' jako nazwę obiektu. Jednak opcja ''verbose_name'' pozwala na manualne dostosowanie tej nazwy, co umożliwia bardziej elastyczne zarządzanie tym, jak nazwa modelu jest prezentowana w różnych miejscach, zwłaszcza w interfejsie administracyjnym.\\
\\
W kontekście interfejsu administracyjnego, ''verbose_name'' jest używane do generowania etykiet i komunikatów w związku z obiektami danego modelu. Na przykład, w panelu administracyjnym Django, zamiast używania automatycznie generowanej nazwy modelu, można dostarczyć bardziej czytelną i spersonalizowaną wersję za pomocą ''verbose_name''.\\
\\
Przykładowo:\\

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        verbose_name = "Awesome Thing"
</code>

Wtedy, zamiast ''"My Model"'', Django będzie używać ''"Awesome Thing"'' jako nazwy pojedynczego obiektu w różnych kontekstach, takich jak interfejs administracyjny.

===== verbose_name_plural =====

Opcja ''verbose_name_plural'' w klasie ''Meta'' modelu Django jest używana do określania czytelnej dla człowieka nazwy w liczbie mnogiej dla zbioru obiektów danego modelu. Jest to szczególnie użyteczne w kontekście interfejsu administracyjnego Django (Django admin) oraz innych miejsc, gdzie prezentowane są dane z modelu w formie tekstowej.\\
\\
Przykład użycia ''verbose_name_plural'':\\

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        verbose_name_plural = "My Custom Model Plurals"
</code>

Domyślnie Django automatycznie generuje nazwę liczby mnogiej na podstawie nazwy modelu, ale ''verbose_name_plural'' pozwala na manualne dostosowanie tej nazwy. To umożliwia bardziej elastyczne zarządzanie tym, jak nazwa zbioru obiektów modelu jest prezentowana w różnych miejscach, zwłaszcza w interfejsie administracyjnym.\\
\\
Przykładowo, jeśli model ma nazwę ''"MyModel"'', Django automatycznie generuje ''"My Models"'' jako nazwę liczby mnogiej. Jednakże, jeśli chcemy, aby nazwa ta była bardziej spersonalizowana, możemy użyć opcji ''verbose_name_plural'':

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        verbose_name_plural = "Awesome Things"
</code>

Wtedy, zamiast ''"My Models"'', Django będzie używać ''"Awesome Things"'' jako nazwy liczby mnogiej w różnych kontekstach, takich jak interfejs administracyjny.

===== label =====

Opcja ''label'' w klasie ''Meta'' modelu Django jest używana do dostosowywania wyświetlanej nazwy modelu w różnych kontekstach, zwłaszcza w interfejsie administracyjnym Django (Django admin).\\
\\
Podstawowo, Django generuje etykietę dla modelu na podstawie jego nazwy. Jednak opcja ''label'' pozwala na dostosowanie tej etykiety w celu uzyskania bardziej spersonalizowanego efektu. Jest to szczególnie użyteczne, gdy nazwa modelu jest techniczna lub skomplikowana, a chcemy dostosować etykietę do bardziej przyjaznej dla użytkownika formy.\\
\\
Przykład użycia ''label'':\\

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        label = "My Custom Model Label"
</code>

W tym przykładzie, zamiast używania domyślnej etykiety generowanej na podstawie nazwy modelu, opcja ''label'' ustawiona jest na ''"My Custom Model Label"''. To umożliwia bardziej elastyczne zarządzanie tym, jak model jest przedstawiany w różnych kontekstach, takich jak interfejs administracyjny.\\
\\
Opcja ta jest stosunkowo rzadko używana, ponieważ w większości przypadków domyślne generowanie etykiety na podstawie nazwy modelu jest wystarczające. Jednak w sytuacjach, gdzie nazwa modelu nie odpowiada idealnie temu, co chcemy wyświetlać, ''label'' pozwala na ręczne dostosowanie tego elementu prezentacji.

===== label_lower =====

W Django opcja ''label_lower'' w klasie ''Meta'' modelu jest używana do dostosowywania wyświetlanej nazwy modelu w różnych kontekstach, takich jak interfejs administracyjny Django (Django admin).\\
\\
Podstawowo, Django generuje etykietę dla modelu na podstawie jego nazwy. Jednak opcja ''label_lower'' pozwala na dostosowanie tej etykiety w celu uzyskania bardziej spersonalizowanego efektu. W szczególności, ''label_lower'' jest stosowane w interfejsie administracyjnym Django, gdzie jest używane do generowania czytelnych dla człowieka komunikatów i etykiet związanych z modelem.\\
\\
Przykład użycia ''label_lower'':\\

<code python>
class MyModel(models.Model):
    name = models.CharField(max_length=100)

    class Meta:
        label_lower = "my custom label"

    def __str__(self):
        return self.name
</code>

W tym przykładzie, zamiast używania domyślnej etykiety generowanej na podstawie nazwy modelu, opcja ''label_lower'' ustawiona jest na ''"my custom label"''. Jest to szczególnie przydatne, gdy nazwa modelu jest techniczna lub skomplikowana, a chcemy dostosować etykietę do bardziej przyjaznej dla użytkownika formy.\\
\\
W praktyce, ''label_lower'' jest używane w celu ułatwienia pracy z modelem w interfejsie administracyjnym Django, poprawy czytelności i dostosowania go do specyfiki aplikacji. Jednak nie ma wpływu na same dane w bazie danych ani na działanie modelu poza kontekstem interfejsu administracyjnego.