Shery és RePa

Tegnap nagy meglepetésemre az Arch Linuxban az alapértelmezett python csomag a 2-es ágból átugrott a 3-asba. (Azaz az eddigi python néven futott csomag python2 néven fut tovább, és a helyét a régi python3 csomag vette át.)

Igaz, hogy minden csomagként érkező pythonos cuccot "portoltak", azaz átírták az interpreterük elérési útját, és a virtulenveknek sem okozott volna egy ilyen váltás problémát, de ezzel párhuzamosan a 2.6-os pythont is frissítették 2.7-esre. Szóval kellett kicsit hackolni, hogy minden menjen, de nagy gond nem volt.

Igazából már régóta tervezem, hogy az apróbb scriptjeimet (amik webhez nem kacsolódnak, mert a python 3-hoz még nincs kész a WSGI szabvány) átportoljam 3-as pythonra, de őszintén szólva enélkül a lépés nélkül ezt sokáig nem tettem volna meg Tegnap azonban a legtöbbnél lefutott a 2to3, és meglepően kevés kézi utánhúzással működtek is.

Szóval - bár drasztikus volt a lépés - így kell ezt csinálni, csak keményen

Pénteken megnéztük az Eredet (Inception) c. filmet, kifejezetten tetszett, na nem mondom, hogy szuper váratlan volt minden fordulat, de akkor is, jó volt. Nézze meg, aki teheti.

Csykin nemrég megszerezte a django.hu domaint, kicsit fel szeretnénk hypeolni itthon is a djangót, illetve a pythont, úgyhogy a szakmaibb postjaim ezután inkább oda mennek, itt is az első komolyabb hangvételű, a singletonokról.

Ha a lenyúlásoknak van diszkrét osztályozása, akkor ez valszeg a "szó szerinti másolás" utáni második fokozat, ráadásul épp a Microsoft által elkövetve - ráadásul épp nemrég volt egy hasonló ügyük. Vad. Persze alvállalkozó volt bizonyára most is.

Egyébként a Plurk szimpatikus próbálkozás, bár én nem szeretem a mikroblogokat, de ha szeretnem, akkor tetszene És ott dolgozik Armin Ronacher, akire a python iránt érdeklődőknek érdemes odafigyelni, talán még húsz éves sincs, de már olyan dolgok fűződnek a nevéhez többek között, mint a Jinja és a Werkzeug.

Tök jó, hogy van pythonban pl. operátor overloading - én legalábbis szeretem, DE:

TM = list
class MyList(TM):
  def __add__(self, a):
    return [self[a[0]]]
 
>>> a = MyList([1,2,3,4,5])
>>> isinstance(a, list)
True
>>> a + [1] # ez lista osszefuzes lenne
[2]

Ilyesmit azért illetlenség csinálni, randa dolgokat eredményezhet, ha egy olyan függvénynek adunk egy ilyen objektumot, ami listát vár. Persze ennek a fordítottja is igaz, és nem csak elrontani tudunk így dolgokat, de megszépíteni is.
Az Class(TM) élő példa, bitbucketen láttam valahol

Ha már megcsináltam, hogy tornado működjön rendesen Solarison is, akkor gondoltam meg is mérem, hogy mennyire rendes az - de legalábbis összehasonlítom az általunk használt hagyományos fascgi megoldással.

Igazából a tornadot nem WSGI appok futtatására találták ki, de azt is tudja, és hát egy tipikus python webalkalmazás belehelyezhető (jó esetben) egy WSGI konténerbe, úgyhogy miért ne. A tesztalkalmazás egy nagyon alap Django project lett, amiben nincs semmi, csak amit a django-admin.py startproject legyárt, illetve egy extra view, ami kiírja ügyesen, hogy Hello World!.

Hat féle felállást hasonlítottam össze, minden előtt volt egy nginx, azért is mert a cucc egy zónában futott, illetve mert a fastcgi-ket nem tudom közvetlen megszólítani "böngészővel":

1. fastcgi/threaded
2. fastcgi/prefork
3. tornado/_Select
4. tornado/_LibEvent
5. nginx/4*tornado
6. haproxy/4*tornado

A mérést az előzőhöz hasonlóan az apache féle ab programmal végeztem, a 1, 10, 100, 1000, 5000 és 10000 párhuzamos klienst szimulálva, az utolsó esetben összesen 50000, egyébként 10000 lekéréssel. Az áteresztő képességen kívül (request/sec) felírtam a kliensek 50/95/99/100%-ának kiszolgálási idejét (milisec). Utóbbi adatokból inkább nem rajzoltam grafikont
Az előzőhöz hasonló módon a teszt egy x86-os Solaris 10-on futott - nem ugyanazon a gépen -, és ugyanúgy minden tesztet háromszor futtattam le, a legjobb eredményt feljegyezve.

Grafikon az áteresztőképességekről:

Konklúzió: a tornado bizony jóval hatékonyabb, mint a sima fastcgik, pláne, ha egy többmagos/többprocesszoros gépen a processzormagok számának megfelelő mennyiségűt indítunk (...reméljük a GIL-től majd megszabadul a python, és akkor ki lehet használni a szálakat rendesen...). Ahogy látszik viszont a _Select alapú ioloopnak meg vannak a korlátai, ha valahol ezt vagyunk kénytelenek használni, ott nginx oldalon tudunk korlátozni, hogy ne kapjon egyszerre mondjuk ezernél több kérést.
Bár a haproxy gyengébben szerepelt, mint az nginx magában, az azért lehet, mert Solaris 10-en még nem támogatja az event ports féle pollingot, csak a régebbi /dev/poll féle megoldást - ennek ellenére jól teljesít, linux alatt valószínűleg ő nyert volna.

A lényeg, hogy a tornado úgy fest valóban képes megbirkózni a tízezer kliens problémájával, és django alkalmazások alatt is jól használható, ha sok klienst kell kiszolgálni.

A nyers számok, ha valakit érdekel: tovább...

Úgy kezdődött a dolog, hogy a facebookos srácok nyílt forrásúvá tették és kiadták a FriendFeed mögött álló python alapú webszervert, a Tornadot. Aranyos dolog, mert nem blokkol, sok klienst képes párhuzamosan kiszolgálni és relatíve gyors mert esemény vezérelt. Feltéve, hogy Linuxon használjuk, mert csak és kizárólag az epollt támogatja (illetve a hagyományos select()-et, nade akkor oda minden előnye).
Viszont én Solaris alatt is szeretném kihasználni a fent említett előnyöket, úgyhogy gyorsan összedobtam egy apró wrappert a libevent köré, ami működik is, és így a Solaris/FreeBSD felhasználók is örülhetnek.

Gyorsan nézzük hogyan történt a dolog.

Először a libeventet kellett letölteni és lefordítani. Szerencsére gond nélkül fordult update 7-es Solaris 10-en.
(jelenleg az 1.4.12-es változat a stabil, azt használtam)

$ ./configure --prefix=/opt/bitnet
...
checking port.h usability... yes # solaris event ports, ez kell nekünk
...
$ make install

Hogy python alól használni tudjuk, ahhoz szükségünk van a python-libevent csomagra, amit én kézzel tettem fel innen, mert a sajtboltos változat ősrégi.

$ export CFLAGS="-I/opt/bitnet/include"
$ export LDFLAGS="-L/opt/bitnet/lib"
$ python setup.py install

Ezután jött az érdemi munka, a tornadot rábeszélni, hogy a libevent-et használja. Ehhez egy ugyan olyan wrapper osztályt csináltam, amit a srácok csináltak maguknak a saját epoll, illetve a hagyományos select() támogatásához, ami igazából a standard python Poll objektum által megvalósított interface:

class _LibEvent(object):
    """A libevent based IOLoop implementation"""
 
    def __init__(self):
        self._eb = libevent.EventBase()
        self._events = {}
        self._ready_fds = {}
 
    def _fd_ready(self, fd, events, eventObj):
        eventmask = (IOLoop.READ * (events & libevent.EV_READ) / libevent.EV_READ) | \
                    (IOLoop.WRITE * (events & libevent.EV_WRITE) / libevent.EV_WRITE) | \
                    (IOLoop.ERROR * (events & libevent.EV_TIMEOUT) / libevent.EV_TIMEOUT)
 
        self._ready_fds[fd] = eventmask
 
    def register(self, fd, events):
        # ezt a reszt is at lehetne alakitani olyanna, mint az elozo fuggveny
        eventmask = 0
        if events & IOLoop.READ:
            eventmask = eventmask | libevent.EV_READ | libevent.EV_PERSIST
        if events & IOLoop.WRITE:
            eventmask = eventmask | libevent.EV_WRITE
        if events & IOLoop.ERROR:
            # does libevent has error event type?
            eventmask = eventmask | libevent.EV_TIMEOUT
 
        self._events[fd] = self._eb.create_event(fd, eventmask, self._fd_ready)
        self._events[fd].add_to_loop()
 
    def modify(self, fd, events):
        self.unregister(fd)
        self.register(fd, events)
 
    def unregister(self, fd):
        self._events[fd].remove_from_loop()
        del self._events[fd]
 
    def poll(self, timeout=10):
        self._ready_fds = {}
 
        self._eb.loop_exit(timeout)
        # libevent.EVLOOP_NONBLOCK hasznalatakor a timert sem varja meg, es megeszi a cpu-t
        self._eb.loop(libevent.EVLOOP_ONCE)
 
        return self._ready_fds.items()
 
...
 
# legvegere, illetve a mar ott levo 'try' blockba:
try:
    import libevent
    _poll = _LibEvent
except:
    _poll = _Select

Illetve ha nem akarjuk belehackolni a tornadoba a cuccot, akkor "monkey patching" technikával is bedolgozhatjuk, ekkor az alkalmazásunk ioloopjanak indítása előtt kell megmondanunk explicite, hogy libeventet használjon:

import tornado.ioloop
tornado.ioloop._poll = _LibEvent
tornado.ioloop.IOLoop.instance().start()

(remélem ezt nem kell sokáig megtenni, jeleztem a fejlesztők felé, hogy jó lenne a libevent támogatást a fő fejlesztési vonalon látni)

Csináltam is néhány gyorstesztet az egyik szerverünkön, sok párhuzamos kérés esetén látszik a fejlődés. A teszteket az apache féle ab paranccsal mértem, ahol az 'n' az összes lekérés, a 'c' pedig a konkurenciát (ennyi szálon próbálkozik párhuzamosan) jelenti. A parancsokat háromszor egymás után megismételtem, és a legjobb eredmény került ki ide.
(ulimit -n unlimited)

1. _Select:
   • n=10000, c=100: 1048.10 [#/sec]
   • n=10000, c=1000: 683.96 [#/sec]
   • n=10000, c=2000: 672.85 [#/sec] (a háromból egyszer meghalt a lenti hibával)
   • n=10000, c=5000: háromszor egymás után: filedescriptor out of range in select()
2. _LibEvent:
   • n=10000, c=100: 1056.57 [#/sec]
   • n=10000, c=1000: 1013.59 [#/sec]
   • n=10000, c=2000: 1004.94 [#/sec]
   • n=10000, c=5000: 954.52 [#/sec]
   • n=10000, c=10000: 781.10 [#/sec]
   • n=20000, c=10000: 934.32 [#/sec]

Első körben nekem elég is volt ennyi, hogy lássam, hogy megérte, aztán majd valami egyszerű webalkalmazással meg kéne nézni, hogy a többi megoldáshoz képest (fcgi, cherrypy, esetleg mod_wsgi) hogy muzsikál a cucc.

Használjátok egészséggel!

Ma a budapest.py keretein belül előadást tartottam a VIM és a Python kapcsolatáról [fóliák itt]. Sztem nem sikerült olyan rosszul, jónéhány ember mintha érdeklődve figyelt volna, pedig azért a téma egy igen szűk réteget érdekelhet

Utánam láthattunk még egy Google App Engine-nel foglalkozó előadást Hardi Jánostól, kedvcsinálónak tökéletes volt (bár nekem van N darab webszerverem, és egyelőre azokat preferálom a Google szervereivel szemben). [video]

Az előadások után elsétáltunk a ligetbe valami szabadtéri szórakozóhelyre meginni egy kólát, jó sokan voltak, de szerintem az alapközönségnek félelmetesek lehettünk, hogy néhány - már ránézésre informatikus - srác olyanokról beszélget egy ilyen helyen, hogy MySQL Cluster, meg Object Relation Mapperek, és így tovább

Igyekszem a következő meetupra is eljutni, ha valakit érdekel a python, jöjjön, esetleg ha van érdekes témája, akkor adjon elő!

Hiánypótló alkalmazással szeretnék előrukkolni, íme a bible.py.

Gondolom már sokatokban felmerült, hogy számítógépen olvasgatnátok a Bibliából, hát itt a lehetőség. A csomag tartalmaz egy sqlite filet, amiben a Biblia található meg soronként magyar és angol nyelven.
(Struktúra: id, könyv, fejezet, sor, nyelv, maga a szöveg)

Összedobtam hozzá egy olvasót pythonban - SQLAlchemy kell neki -, amivel gyorsan idézhetünk, ha kedvünk tartja. Persze az "API" közel sem teljes, de kiindulásnak jó, és igen könnyen lehet belőle webes alkalmazást csinálni.

Használat:

# egy sor
$ ./bible.py mt 13:4
Mert Isten szolgája õ a te javadra. Ha pedig a gonoszt cselekszed, félj: mert nem ok nélkül viseli a fegyvert: mert Isten szolgája, bosszúálló a haragra annak, a ki gonoszt cselekszik.
# több sor, angolul
$ ./bible.py mt 5:3-6 en
Blessed are the poor in spirit: for theirs is the kingdom of heaven.
Blessed are they that mourn: for they shall be comforted.
Blessed are the meek: for they shall inherit the earth.
Blessed are they which do hunger and thirst after righteousness: for they shall be filled.

Használjátok egészséggel, illetve ha valami hasznosat tesztek a kódhoz, küldjétek vissza, és kiteszem azt is.

Megjelent a végleges python 3000!
(Túl sok változás nem történt az előző postjaim óta.)

Pythonra fel!

Ugye egy ideje már mudozok, aztán felmerült bennem, hogy néha logolni kéne a történéseket, megmutatni másoknak, vagy csak visszanézni, ha valami komolyban vettem részt. A tf tud logolni, de csak plain textben, azaz elvesznek a színek, és eléggé nehezen lesz áttekinthető a dolog.

Múlt héten, hogy pihentem, írtam egy kicsi scriptet (python ofc) [mudlogger.py], amit proxyként használva az szépen menti a teljes forgalmat. Ezután csak egy másik script kellett [logreader.py], ami az ANSI "formátumot" HTML-é konvertálja.

Példa kimenet. Az ogre kovácsot kérem meg finoman, hogy pihenjen.

Természetesen nem csak mud forgalom logolására képes a cucc, használjátok egészséggel.

Megjelent.

Elérhető benne szinte minden, ami a 3.0-ban benne lesz, csak még kompatibilis a régi verziókkal.
Amit most így hirtelen kiemelnék az újdonságok közül az a multiprocessing modul, és mostmár alapból jön a pythonnal json modul is. Illetve hát a dokumentációt is szép színes-szagos köntösben olvashatjuk (a Sphinx project jóvoltából).

Mindjárt itt a 3.0 is!

Mármint én nem, sőt, de Cal Henderson, a Flikr vezető fejlesztője ezzel a címmel tartott egy előadást a nemrég zajott DjangoCon konferencián. Nem rövid, most volt csak időm megnézni, de érdemes volt, nagyon tetszik a srác stílusa.

A mondanivaló szintén nem butaság, bár egyelőre nekem - eddig még - nem volt szükségem nagyonnagy adatbázisok kezelésére.

A kulcsprobéma azonban - hogy a Djangónak nincs kabalaállata - megoldódott azóta:

Végre megjelent!

Stabil API - ami azt jelenti, hogy az 1.0-s Django alkalmazások változtatás nélkül fognak futni a többi 1.x kiadáson -, és eltűnt a figyelmeztetés is, hogy nem ajánlják éles használatra. Rengeteg új feature (nem csak az előző 0.96-os változathoz képest, csak az elmúlt másfél hónapban több jelentős változás került bele a kódba), megújult dokumentáció, és a már megismert sebesség és stabilitás.

Aki webet fejleszt, nem zárkózik el az új dolgoktól, és még nem próbálta volna ki, annak mindenképpen ajánlom.

A python 3.0-ban jelennek meg a függvény argumentum megjegyzések (annotations, nemtom minek lehetne értelmesen fordítani), ami amellett, hogy dokumentációs célokat szolgál, segítségével megvalósítható python alatt is a függvény paraméterek típusellenőrzése (mert az egyébként nincs).

Maga az ellenőrzés nem lesz része a python 3.0-nak, és mindenhol azt írják, hogy egyszerű megcsinálni, de mivel sehol sem találtam meg, ezért megcsináltam magam. És valóban, egy egyszerű dekorátor függvény teszi, ami nekünk kell:

import inspect
 
def typecheck(func):
  def inner(*args, **kwargs):
    # check *args
    valueiter = iter(func.__annotations__.values())
    for arg in args:
      argclass = next(valueiter)
      if not inspect.isclass(argclass):
        continue
      if not issubclass(arg.__class__, argclass):
        raise TypeError("Hibas bejovo parameter!")
    # check **kwargs
    for arg in kwargs:
      if not arg in func.__annotations__ or not inspect.isclass(func.__annotations__[arg]):
        continue
      if not issubclass(kwargs[arg].__class__, func.__annotations__[arg]):
        raise TypeError("Hibas bejovo parameter!")
    # call the function
    return func(*args, **kwargs)
  return inner

Nézzük működés közben:

@typecheck
def a(alma: int, beka: str = "szia", mokus: int = 2):
  print(alma, beka, mokus)
 
>>> a(1, mokus=10)
1 szia 10
>>> a(1, mokus=10, beka=3)
Traceback (most recent call last):
  File "stdin", line 1, in module
  File "stdin", line 16, in inner
TypeError: Hibas bejovo parameter!
>>> a(1, beka="hello")
1 hello 2

Persze ez csak egy gyors megoldás, érdemes lenne a hibaüzenetben kiírni, hogy melyik paraméter hibás, ezt az érdeklődők megírhatják kommentben.

Pythonra fel!

Nemrég, hogy megjelent a python 3.0 beta (sőt, lassan itt a beta 2), úgy gondoltam, hogy megnézem mostmár mit tud. Eddig is olvasgattam, hogy a 2.x vonalhoz képest bizony változik az API, bár mivel a 2-es vonal is folytatódik, és több dologgal is segítik az áttérést, túl nagy gondok valószínűleg nem lesznek. A python 2.6 képes (lesz majd) jelezni, ha nem 3.0 kompatibilis dolgokat használ az ember, és ha már csak azokat használ, akkor van egy tool - a 2to3 -, ami az esetek 99%-ában automatikusan átalakítja a forrás py3k kompatibilissé.

Na nézzük röviden mit kapunk. tovább...

Egyik futo projectben felmerult, hogy hogy osztunk meg weben tartalmat ugy a neppel, hogy rendes access controlunk lehessen. Azaz pl. lehessen alligatni userenkent savszelesseget, hozzaferesi idot, es minden butasagot, ami csak eszunkbe jut.

Alapbol ugye van a webszerver oldali .htaccess es baratai megoldas, ahol eleg szukosek a lehetosegek, es hat nem is egy olyan kifinomult admin feluletunk van, mint a djangonak. De kigondoltam valamit, igaz a modszer nem tul hatekony - az eroforrasok szempontjabol -, de mindent lehet, amit mi akarunk, es majd max kap a gep +10% procit es memoriat.

Az alapotlet az, hogy nem kozvetlen a webszerver adja vissza a filet a kliensnek, hanem az csak egy cgi/fcgi scripttol keri azt el, ami szepen "felolvassa" azt a merevlemezrol, felteve, hogy a felhasznalonak ezt mi megengedtuk.
Ezt egyebkent egy akarmilyen scriptnyelvben nevetsegesen egyszeru megcsinalni, pl. phpban:

$filename = "/ez/a/file/kell";
header('Content-Type: ilyentipusuafile');
header('Content-Length: afilehossza');
readfile($filename);

Szoval egyatalan nem bonyolult.

Djangoban azonban nem talaltam olyat, hogyan adok vissza nem tipikus tartalmat. Az alap HttpResponse-t nem arra talaltak ki, hogy szepen olvassa fel a fileokat a winyorol, ugyhogy - eljen az OOP - leszarmaztattam belole, es ime az eredmeny.
Djangoban ezutan csak egy view kell, ami ellenorzi, hogy megfelelo-e minden feltetel (be van-e lepve a felhasznalo, a megadott idopontban tolthet-e le, kek-e a szeme, es hithu kereszteny-e), es ha igen, akkor egy egyszeru return HttpFileResponse(fileneve), es a file mar uton is van.

Nincs meg kesz persze, de akinek kell, az vigye, akinek meg van valami jo otlete, az szoljon! (A kod egyebkent a kb. 3 hettel ezelotti svn trunk alapjan keszult, stabil 0.96-os djangoval, vagy a legfrissebb fejlszetoi anyaggal nem feltetlen mukodik, de sokat tuti nem kell rajta dolgozni, hogy menjen.)

Ha van ket programunk, es mi azt szeretnenk, hogy az egyik beszelgessen a masikkal, akkor sokfele IPC megoldas kozul valaszthatunk, a hagyomanyosoktol kezdve (szemafor, socket, ...) a modernebbekig (pl. CORBA, RMI, ...) eleg sokmindent valaszthatunk. Utobbiak koze tartozik a DBUS, melyet a modern linux disztribuciok kivetel nelkul tartalmaznak.

Nezzunk egy egyszeru peldat arra, hogy ezt az uzenet-buszt az egyszeru halando hogyan hasznalhatja. Eszkozkent termeszetesen a sokak altal meltan kedvelt python nyelvet valasztottam
Ubuntu/debian alatt a python-dbus csomag tartalmazza a szukseges dolgokat.

Nezzuk gyorsan, hogy nez ki egy uj szolgaltatas, utana fuzok hozza egy kis magyarazatot:

import dbus, dbus.service, dbus.glib
import gobject
 
class ButaService(dbus.service.Object):
 
  @dbus.service.method(dbus_interface='hu.horak.ButaInterface',
                       in_signature='s', out_signature='')
  def irjadki(self, szoveg):
    print "Ez jott: %s" % szoveg
 
bus = dbus.SessionBus()
name = dbus.service.BusName('hu.horak.ButaServer', bus=bus)
obj = ButaService(name, '/')
 
loop = gobject.MainLoop()
print 'Figyelek...'
loop.run()

Amint lathato eloszor letrehozzuk a szolgaltatasunkhoz tartozo osztalyt, a dbus.service.Object osztalybol szarmaztatva. Ezen osztaly metodusait exportalhatjuk szolgaltataskent a dbus.service.method dekorator fuggvennyel - ennek a szolgaltatasi felulet nevet kell megadni, illetve a bejovo es kimeno parameterek tipusat - ami pythonban ugye nem egyertelmu, dbuson viszont annak kell lennie.
A szolgaltatasunkat mikor peldanyositjuk, az regisztralja magat egy mar meglevo busznal. Alapertelmezetten ket ilyen busz van, a SessionBus, ami a bejelentkezett felhasznaloknak a sajatja, illetve a SystemBus, ahol a rendszeruzenetek szaladgalnak. Mivel utobbihoz csak rendszergazdai jogokkal tudunk szolgaltatast hozzaadni, ezert az elobbit illik valasztanunk.
Ha kesz a szolgaltatasunk mar csak varni kell, hogy valami kliens hasznalja is azt, ehhez szuksegunk van egy glib kompatibilis mainloopra. Elinditjuk, es varjuk, hogy az elso kliens uzenetet kuldjon nekunk...

...amit meg ennel is joval egyszerubb:

import dbus, dbus.glib
 
bus = dbus.SessionBus()
 
server = dbus.Interface(bus.get_object('hu.horak.ButaServer', '/'),
                        'hu.horak.ButaInterface')
server.irjadki("helloszia")

A kliens egyszeruen annyit csinal, hogy lekeri a beregisztralt szolgaltatasunkat (illetve egy helyi proxy-objektumot keszit, ami vegulis tarsalog a szerver oldallal), majd meghivja az exportalt metodusat. A szerver oldalon pedig megjelenik az "Ez jott: helloszia" uzenet.

Pofonegyszeru. Persze nem arra van kitalalva, hogy masodpercenkent tobbmillio uzenetet kuldozgessunk...
Akit jobban erdekel a tema megnezheti az eredeti tutorialt.

Csykinnek fejlesztettem nemreg egy szoftvert (lenyegtelen mit csinal), python alapu, es mysql-t hasznal az adatok tarolasara. Termeszetesen az alkalmazas egyetlen DBHandler nevu osztalyon keresztul kapcsolodik az adatbazishoz, aminek egy leszarmaztatott osztalya a MysqlDBHandler, igy egy sor modositasaval (es egy uj adatbaziskezelo osztaly hozzaadasaval) barmilyen mas adatbazis is hasznalhato lenne. De ebben nincs semmi kulonos, ezt minimum igy illik csinalni.

Viszont a mysql adatbazist ha a valaki az alkalmazason kivulrol szeretne piszkalni, akkor mar nincs olyan jo dolga, vagy parancssorozik, phpmysqladminozik, esetleg ir hozza valami feluletet, amin keresztul nezegetheti. Ellenben eszembe jutott, hogy mi lenne, ha az adatok tarolasara a djangot kernem meg - ezesetben a generalt admin feluleten keresztul egyszeruen elerhetem az adatokat, sot szep webes statisztikakat is eleg egyszeruen tudok utana csinalni. Ugyhogy nekialltam... tovább...