Nicola Larosa ha scritto:
Nicola Larosa ha scritto:
Ovviamente l'ideale, usando Twisted, sarebbe di non usare per niente i
thread, o almeno limitarli all'indispensabile, come l'accesso al
database. In quel caso non si può passare per WSGI, che non supporta
gli eventi asincroni, ma bisogna scrivere un apposito handler di
Django usando oculatamente i Deferred di Twisted (magari completando
quello già iniziato che mi ritrovo casualmente sul disco ;-D ).
Manlio Perillo wrote:
Ti stai riferendo a: http://code.djangoproject.com/ticket/2904 ?
No, non l'avevo visto, grazie per il riferimento. Mi riferisco a un abbozzo
di handler scritto da un mio amico (hi, pr0gg3d!) col mio aiuto.
Il ticket da te indicato cerca di mantenere la compatibilità con WSGI: il
nostro cerca di integrare direttamente Twisted e Django.
Avete pensato di aprire un ticket su django?
A quel punto l'intera architettura è asincrona, tranne le parti dove
si continuano a usare i thread, e bisogna seguire ovunque il principio
guida di Twisted di non scrivere codice bloccante.
La vedo ardua dato che puoi accedere a codice bloccante in modo non
controllabile quando usi un database.
Ad esempio, a quanto ho capito, viene usato sempre il lazy loading,
quindi una chiamata a obj.xxx può causare una query.
Questo è infatti lo scoglio principale.
Quindi mi confermi che non si può disabilitare ed usare invece un eager
loading.
Una soluzione potrebbe essere quella di eseguire l'intera view in un
thread (e transazione) separati.
Questo approccio è meno invasivo, non devi propagare tanti Deferred in
giro, però non è molto diverso dall'approccio attuale via WSGI.
Esattamente.
L'unico vantaggio è che decido io cosa far girare in un thread separato
e a volte conviene farci girare l'intera view.
Pensa inoltre a cosa succede con le generic view e l'interfaccia
amministrativa!
E' quello che volevo fare con Nevow, ma SQLAlchemy si è rivelato molto
flessibile. Quello che ho fatto è stato semplicemente scrivere dei
decoratori:
@engine.transact def getXXXList(conn, ...): ...
@engine.transactSession def getYYYList(conn, sess, ...): ...
Abbiamo fatto qualcosa di molto simile, con SQLAlchemy e Twisted, in un
progetto a cui sto lavorando.
Io lo sto per publicare:
http://developer.berlios.de/projects/nadbapi
Credo sia venuto fuori abbastanza bene.
Ho implementato un:
- Pool
- Engine
- MetaData
personalizzati per Twisted, che permettono una buona integrazione
(ad esempio engine.create(foo) restituisce una deferred,
e lo stesso foo.select().execute() - se lo si vuole, io di solito
preferisco usare i decoratori.
Se interessa, sto per publicare anche l'altro progetto per la gestione
dei forms:
http://developer.berlios.de/projects/nforms
A breve seguiranno la mia reimplementazione di guard e un package per la
gestione di un calendario (ispirato allo standard ical).
Non ho idea se lo stesso si possa fare agevolmente con Django (e devo
dire che non ho molta voglia di indagare).
L'approccio "light" continua a essere sostanzialmente multithreaded, cosa
già fornita dall'integrazione WSGI. L'approccio invasivo converte una
maggior parte dell'architettura al modello di Twisted, ma da un lato non è
facile da scrivere, e dall'altro sconvolge le API di Django e lo rende
incompatibile con i siti sviluppati per la versione ufficiale.
E ne vale la pena? ;-)
Non si fa prima a copiare alcune idee di Django e portarle a
Twisted Web + SQLAlchemy ?
Saluti Manlio Perillo
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
