Wednesday, February 22, 2006

Django reminders

Doua linkuri care pot ajuta si alti Django-users din .ro:

- In caz ca folositi Django 0.91 si o varianta recenta de MySQL, aveti grija la asta: "MySQL 5.0.3+ and meta.FloatFields don't mix". Am avut aceeasi problema ca acolo, cu eroarea "TypeError: Float argument required", la orice valoare as fi introdus, fie 1.0, 1, or whatever. Noroc ca prietenul nostru Google a indexat ticket-ul respectiv, si l-a pus si primul in search results :). Fixul descris in comentarii merge, desi e cam "hacker-ish". Probabil urmatorea versiune va avea inclus un fix mai bun.

- In caz ca vreti sa accesati "modelele" definite in Django din afara aplicatiei web propriu-zise, de exemplu daca ati creat un script Python care sa populeze baza de date a aplicatiei Django fara a porni serverul propriu-zis, atunci linkul asta o sa va ajute: using model classes without a server.
Aveam nevoie sa populez baza de date a unei aplicatii Django cu datele stocate anterior intr-un fisier "pickle", prin urmare imi trebuia un script care sa poate accesa "modelele" definite in Django din afara aplicatiei web. Problema era ca la inceput de fiecare data imi aparea eroarea "DJANGO_SETTINGS_MODULE not set", pana am vazut mesajul din linkul de mai sus si pe urma lucrurile au fost ok.

Tuesday, February 14, 2006

Cand inveti ceva nou

Cred ca pentru prima oara in ultimele opt luni am in sfarsit timp sa invat ceva nou asa cum imi place mie, cu documentatie trasa la imprimanta, navigand prin arhivele de mailing listuri cautand sa vad care sunt cele mai comune probleme si cum trebuie rezolvate, citind bloguri asupra subiectului... Mi-am adus aminte de cum am invatat Python acum aproape trei ani de zile, cand cred ca in fiecare zi stateam cel putin o ora citind Python mailing list, desi si atunci aveam scoala si un job (de noapte), sau mai tarziu cum umblam prin tramvaie cu foi trase la imprimanta in care se explica care e cea mai eficienta metoda pentru impartirea automata pe categorii.

Saturday, February 11, 2006

Recursivitatea in template-urile Django

Link rapid: Recursion in Django Templates.
Destul de complicat. In template-urile din Zope am rezolvat problema asta folosind doua "macro-uri" si un script python, care returna copiii unui anumit nod.

Tuesday, February 07, 2006

Despre Django

In mai putin de doua saptamani voi avea un nou job, las la o parte Zope-ul si voi trece pe Django. Drept pentru care am inceput sa vad ce poate "Django in actiune" :)
Pentru inceput iata cateva lucruri care imi plac la Django:
- Fisierele de configurare sunt in Python. Un mare plus. Spun asta ca unul care de o luna - o luna jumate ma lupt cu editarea fisierelor de configurare in format XML. Postul asta, pe nume "Python is not Java", ar trebui sa fie un must-read pentru oricine se intampla "sa ia decizii" intr-un shop Python. Din pacate nu se intampla asa, dar asta deja e alta problema. Celor carcotasi ca mine cand vine vorba de fisiere XML de configuare li se spune "get a good editor, that can trigger the red alarm if your XML file is broken". Intrebarea e "ce e rau cu bietul meu editor Python, ce nu intelege XML?".
- Pana nu demult credeam ca ZODB-ul "batea la fund" RDBMS-urile PostgreSQL sau MySQL. Nu atat din punct de vedere al performantei, cat din punct de vedere conceptual. Imi zaceam ca e mult mai misto ideea de a stoca obiecte ce pot avea atasate atribute, metode etc. Pe cand in MySQL de exemplu se stocheaza pur si simplu niste data "chioare". Am inceput sa am primele dubii privind ZODB-ul odata cu prima "POSKey Error". Asta e o eroare care se datoreaza unor date corupte, si care in mod normal nu ar trebui sa apara, conform unuia din principalii developeri din spatele ZODB, dar asta nu e de nici un ajutor cand clientul tipa ca vrea sa scape de ea. Cum gasesti acele date corupte si cum rezolvi problema lor e treaba ta, dar pana faci asta s-ar putea sa ai norocul ca nici o cautare in ZMI sa nu-ti mearga. Alta problema legata de ZODB e ca pentru un numar relativ modest de intrari (sub 100.000, sa zicem), s-ar putea sa ai bafta sa ai un numar de conflicte anormal de mare. Solutia? "Upgrade to the latest ZODB version". Ce se intampla cand ai 1.000.000 de intrari in ZODB si cat de repede mai merge atunci "jucaria" ramane ca tema pentru cititor :) Pe cand toate RDBMS-urile (cel putin cele care se respecta) se descurca confortabil atunci cand au 1.000.000 de intrari (desigur, daca baza de date nu a fost proiectata cu picioarele). Alt punct in minus pentru ZODB este ca poti avea acces la date doar programatic, prin intermediul scripturilor Python, pe cand in cazul unei baze de date MySQL ce sta in spatele unei instante Django pot inspecta si chiar modifica datele cu un produs ca phpMyAdmin, de exemplu, ce nu are nici o legatura cu Django. Asta numesc eu "loose coupling".
E deja tarziu:) o sa revin cat de curand cu alte impresii despre Django.