Helper dla Pagination w Django

Wyświetlanie dużej ilości pozycji w aplikacji webowej jest zwykle związane z koniecznością zastosowania paginacji stron. Dobra nowina – Django takowego posiada. Zła nowina – brakuje w nim jednej prostej funkcji.

Ów funkcją jest zawężenie ilości stron do określonej ilości (lub odległości od aktualnie wybranej) i wstawienie wielokropków w określonych miejscach. Śpieszę więc z moim rozwiązaniem.

Aktualizacja: W kodzie funkcji został poprawiony drobny błąd logiczny oraz dodana została obsługa czegoś co nazwałem bounce – czyli „odbijania się”; polega to na tym, że jeśli wybrana jest strona druga, zakres wynosi 3, to z prawej strony widzimy elementy 3, 4, 5 oraz dzięki odbiciu – 6, 7, które powinny być widoczne po lewej stronie, ale wykroczyłoby poza zakres dostępnych stron. Podobnie paginator zachowa się, jeśli odwiedzalibyśmy ostatnie strony. Ta niewielka poprawka sprawia, że paginator zachowuje się znacznie przyjaźniej dla użytkownika. Przykładowe zastosowanie można objerzeć na stronie, dla której go stworzyłem – to strona z przepisami kuchennymi

#!/usr/bin/env python
# -*- coding: utf-8 -*-

def ranged_pages (pages, current, dist, border):
 """ Zwraca fragment listy /pages/ zawężoną do /dist/ wokół /current/
 oraz oddalone o /border/ od początku i końca listy """
    if bounce:
        bounce_left = pages.index(current)-dist
        bounce_right = len(pages)-pages.index(current)-1-dist
        if bounce_left < 0:
            dist += abs(bounce_left)
        if bounce_right < 0:
            dist += abs(bounce_right)
    return map(lambda x: [None,x][(x > current-dist-1) &
        (x < current+dist+1) | (pages.index(x) < border) |
        (pages.index(x) > len(pages)-border-1)],
        filter(lambda x: (x > current-dist-1) &
        (x < current+dist+1) | (pages.index(x) < border+1) |
        (pages.index(x) > len(pages)-border-2), pages))

# przykładowe zastosowanie:

pages = map(lambda x:x,range(1,25))
print 'dane wejsciowe:\n%s\n' % pages

print 'aktualny:%d, dystans:%d, od_granic:%d\n%s\n' % \
 ( 12,3,2, ranged_pages(pages, 12, 3, 2))

print 'aktualny:%d, dystans:%d, od_granic:%d\n%s\n' % \
 ( 5,4,3, ranged_pages(pages, 5, 4, 3))

Funkcja ranged_pages zajmuje się całym zadaniem. Jest ona jednocześnie przykładem jak można pisać efektywnego jednolinijkowca, który jest nieczytelny i brzydki jak noc.

Parametry które przyjmuje funkcja to kolejno:

• lista stron z Pagination(objects).page_range
• indeks aktualnej strony
• ilość stron na lewo i prawo od aktualnej, które mają być wyświetlane
• ilość stron od początku i końca listy

Po uruchomieniu przedstawionego wyżej przykładu dostajemy następujący wynik:

dane wejsciowe:
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24]

aktualny:12, dystans:3, od_granic:2
[1, 2, None, 9, 10, 11, 12, 13, 14, 15, None, 23, 24]

aktualny:5, dystans:4, od_granic:3
[1, 2, 3, 4, 5, 6, 7, 8, 9, None, 22, 23, 24]

Pozycję None oczywiście podmieniamy wielokropkiem. Robimy to już w konkretnym template.

Dlaczego nazwałem to helperem? Taką konwencję przyjąłem już dawno temu – większość funkcji konkretnej aplikacji które wykorzystywane są przez views.py umieszczam w pliku helpers.py z którego importuje do widoków. Rozwiązanie sprawdza się świetnie, szczególnie jeśli do kodu jakiegoś projektu nie zaglądam zbyt często – nie trzeba się głowić gdzie takie usprawniacze trzymamy.

Jeśli w swoim kodzie nie stosujesz zbyt często funkcji lambda, map, reduce i filter, uważam, że warto zapoznać się z ich dokumentacją. Inne przykłady ich praktycznego zastosowania przedstawiłem we wpisie po angielsku opisującym prosty konwerter CIDR na maskę bitową.

Wygodny storage z użyciem memcache w Django

Czasami zachodzi konieczność napisania na szybko aplikacji w Django która standardowo coś tam trzyma w bazie danych, coś przetwarza i wyświetla. Jeśli aplikacja ma być prosta, a w bazie mają być trzymane proste struktury danych, to czy napewno musimy tyle czasu poświęcać na dopracowanie modeli? Jasne, że nie.

Poniższy kod oferuje nam możliwość trzymania dowolnych danych w postaci klucz-wartość w bazie danych. Dodatkowo – owe dane mogą mieć dowolną postać – może być to tekst, tablica asocjacyjna czy wartość typu Boolean.

Ponadto – biblioteczka ta opiera się o opisaną w poprzednim wpisie obsługę memcache’u w Django – co sprawia, że do póki nie zmienimy wartości danych, a ich obecność w cache’u nie zdąży wygasnąć – nie będziemy w ogóle obciążać naszej bazy danych. Osobiście wykorzystuję ten kod do trzymania ustawień aplikacji. Niektóre ustawienia są typu boolean, inne to stringi, jeszcze inne – tabele. Rozwiązanie sprawdza się świetnie.

Właściwy kod

Modele – models.py:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# Copyright (c) 2009 nme.pl
# Dual licensed under MIT and GPL.

from django.db import models

class Vars (models.Model):

    key = models.CharField(max_length=50)
    value = models.TextField()

Proste prawda? Nie zapomnijcie wydać komendy django-admin syncdb która utworzy odpowiednią tabelę w bazie. Teraz czas na właściwą bibliotekę – vars.py:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
#
# Copyright (c) 2009 nme.pl
# Dual licensed under MIT and GPL.

""" Simple variables (key-value) handling with memcache """

import pickle,base64

import memcache,models

from settings import conf

class __Vars:

    def get (self,key,default=None):

        """ get Vars variable value """

        if memcache.enabled:
            value = memcache.get('va-%s' % key)
            if value != None:
                return pickle.loads(base64.b64decode(str(value)))
        settings = models.Vars.objects.filter(key=key)
        if settings:
            value = settings[0].value
            if value:
                return pickle.loads(base64.b64decode(str(value)))
            else:
                return default
        else:
            return default

    def __getitem__ (self,msg):

        return self.get(key)

    def set (self,key,value):

        """ set Vars variable value """

        value = base64.b64encode(pickle.dumps(value))
        if memcache.enabled:
            memcache.set('va-%s' % key,value)
        settings = models.Vars.objects.filter(key=key)
        if settings:
            setting = settings[0]
            setting.value = value
            setting.save()
        else:
            models.Vars(key=key,value=value).save()

    def has_key (self,key):

        """ return True or False if Vars variable exists """

        settings = models.Vars.objects.filter(key=key)
        if settings:
            return True
        else:
            return False

    def delete (self,key):

        """ deletes given key from Vars and memcache """

        if memcache.enabled:
            memcache.delete('va-%s' % key)
        settings = models.Vars.objects.filter(key=key)
        for i in settings:
            i.delete()

variables = __Vars()

Przykładowe użycie

Zastosowanie biblioteki z poziomu django-admin shell:

In [1]: from vars import variables

In [2]: if not variables.has_key('test'):
   ...:     variables.set('test','tekst')
   ...:
   ...:     

In [3]: print variables.get('test')
tekst

In [4]: variables.set('test',{'asd':1,'data':['struct','ure']})

In [5]: variables.get('test')['data'][1]
Out[5]: 'ure'

In [6]: variables.delete('test')

In [7]: variables.get('test')

In [8]: variables.has_key('test')
Out[8]: False

Jak to działa?

Składowanie dowolnego typu danych w rekordzie bazy zrealizowane jest w oparciu o dwie standardowe biblioteki pythonowe – pickle i base64. Pierwsza z nich oferuje zakodowanie dowolnej struktury danych do stringa, druga natomiast – zastosowanie notacji base64 – przez co zabezpieczamy się przed ewentualnymi problemami z obsługą znaków z którymi nasz bazodanowy backend mógłby mieć ewentualnie problemy. Innymi słowy – rozwiązanie przedstawione powyżej gwarantuje nam pełną przenośność danych.

Zachęcam gorąco do korzystania

Memcache w Django: krok ku lepszej skalowalności

Podczas tworzenia aplikacji webowych, warto w miarę wcześnie pomyśleć o skali z jaką nasze rozwiązanie będzie miało się w przyszłości zmierzyć. Niezależnie od tego czy owa aplikacja ma pracować w jednym przedsiębiorstwie, czy próbuje zainstnieć szerzej, w sieci – w każdym przypadku może się okazać, że odniesie sukces. To z kolei sprawi, że ilość jej użytkowników urośnie… Firma może się rozwinąć, przejąć konkurencję, aplikacja webowa może się okazać takim strzałem w dziesiątkę jak nie tak dawno temu Nasza-Klasa – nigdy nie wiadomo W momencie gdy miałaby go odnieść, nie będzie już zbyt wiele czasu na przebudowę kodu, a napewno nie będzie go na jego całkowitą reorganizację.

Jeśli rozwiązanie jest skryptem uruchamianym od święta – może to być zwykły skrypt CGI. Jeśli jednak miałby być uruchamiany częściej – wartałoby już pomyśleć o mod_php czy mod_python… Albo jeszcze lepiej – fastcgi, a w przypadku pythona – wsgi. Kiedy użycie aplikacji rośnie nadal – frontend mnożymy na kolejne węzły stawiając przed nimi balancera robiącego za reverse proxy. A w backendzie klastrujemy… ale co na styku macierz, klaster? Ilość zapytań do bazy rośnie, io waity zaczynają rosnąć i robi się nieciekawie… Da się to rozwiązać?

Jak to robi Google

Google od jakiegoś czasu pokazuje nam jak powinny być tworzone intensywnie wykorzystywane aplikacje webowe i na jak zorganizowanym backendzie powinny pracować, aby skalowały się najefektywniej. Myślę, że warto z tej wiedzy skorzystać zanim io waity zaczną spędzać nam sen z powiek.

Miałem okazję napisać sobie kilka małych aplikacji które pracują w chmurze na platformie Google – tzw. Google App Engine (w skrócie GAE). Warto było poświęcić trochę czasu aby to rozwiązanie poznać. Łatwiej było mi dzięki temu można zrozumieć między innymi dlaczego poszczególne serwery Google nie są potężnymi serwerami rackowymi z bardzo silnymi procesorami, ale raczej „lżejszymi” serwerkami, ale za to wypełnionymi po brzegi koścmi pamięci.

Dlaczego takie lżejsze maszyny? Poza oszczędnością energii i pieniędzy są one wystarczające do obsługi pythonowych frameworków, w przeciwieństwie do tych PHP’owych.

Google skupia się na Javie i Pythonie, gdzie prawie pewne jest to, że ich rozproszony Datastore – system bazodanowy, został stworzony w oparciu o język Python. Język ten znany jest m.in z wydajności, szczególnie, jeśli osoba która go używa stosuje się do najbardziej podstawowych zasad jak nie allokowanie ogromnej ilości pamięci itp. Dlaczego więc w serwerach Google tyle pamięci? Odpowiedzią jest memcache.

Google chwali się tym, że stworzyli sobie własną implementację cache, inspirowaną oprogramowaniem memcached i zachęca, aby developerzy aplikacji App Engine’owych również korzystali z memcache’a.

Na czym polega memcache

Uproszczony graf przedstawiający działanie memcache’u:

Koncepcja działania jest prosta – zamiast odwoływać się bezpośrednio do bazy danych, odwołujemy się do memcache’a – jeśli trafiliśmy na dane (hit), wykorzystujemy je, jeśli nie (miss), dopiero wtedy odwołujemy się do bazy, jednocześnie zapisując pobrane z bazy dane w naszym cache’u. Dzięki temu prostemu zabiegowi, nasza strona, która podczas każdego odwołania do niej potrzebuje jakichś danych z bazy, jest w stanie funkcjonować praktycznie w ogóle jej o nic nie odpytując – wszystko co potrzebne będzie trzymać w pamięci podręcznej.

Zastosowanie i dokumentacja

Aby wykorzystać memcache w Google App Engine, polecam zapoznanie się z dokumentacją na stronach Google.

A co jeśli chcielibyśmy wykorzystać memcache w Django? Naturalnie – nic nie stoi na przeszkodzie – Django posiada coś takiego jak cache framework, który na dodatek jest bardzo dobrze udokumentowany.

Django samo z siebie jest przystosowane do wykorzystania cache’u przy obsłudze widoków czy template’ów, ale również oferuje dostęp niskopoziomowy – niemalże analogiczny do tego z Google App Engine… Niemalże, bo jakoś wersja Google bardziej przypadła mi do gustu. Dlatego przygotowałem sobie prosty interfejs, który wydaje mi się być odrobinę bardziej logiczny. Kod oczywiście załączam. Mam nadzieję, że komuś się przyda.

Konfiguracja systemu, projektu Django oraz moja niskopoziomowa obsługa

Zakładając, że pracujemy na systemie GNU Debian/Ubuntu oraz Django jest już w systemie jakąś drogą zainstalowane (osobiście w tym akurat przypadku polecam instalację z oryginalnych źródeł nad paczką Django z dystrybucji), doinstalowujemy obługę memcached, włączamy ją i restartujemy demona memcached:

sudo -i
aptitude install memcached python-memcache
sed -i 's/no/yes/' /etc/default/memcached
service memcached restart
exit

teraz w naszym projekcie Django włączamy obsługę cache:

w pliku settings.py:

CACHE_BACKEND = 'memcached://127.0.0.1:11211/'

jeśli chcemy wykorzystać moją małą biblioteczkę poniżej, do settings.py musimy dodać też konfigurację memcache:

class conf:
    class memcache:
        disabled = False
        timeout = 600

Moja niskopoziomowa obsługa memcache.py:

#!/usr/bin/python
# -*- coding: utf-8 -*-

""" cache low-level backend based on memcached """

from django.core.cache import cache

from settings import conf

def get(key, default=None, timeout=conf.memcache.timeout):

    """ returns value for given key from cache, and refreshes it
    in memcache with automatic conversion from unicode
    to str - fix to:
    __import__() argument 1 must be string without null bytes, not str """

    value = cache.get(key, default)

    if value is not default:
        cache.set(key, value, timeout)

    if type(value) is unicode:
        value = str(value)

    return value

def set(key, value, timeout=conf.memcache.timeout):

    """ sets a value for given key in cache """

    cache.set(key, value, timeout)

def delete(key):

    """ remove given key from cache """

    cache.delete(key)

# in the name of syntatic sugar  

disabled = bool(conf.memcache.disabled)
enabled = not disabled

A przykład zastosowania pojawi się jutro albo pojutrze – w nowym wpisie.