2015-12-22 17:59 GMT+01:00 Luca <luca...@gmail.com>: > Salve a tutti, > > Chiedo se qualcuno sa. > > Ho una situazione del genere: > > - nginx. > - uwsgi. > - djnago wsgi application. > - postgresql uno schema public e circa 170 schemi *per user*. > - sqlalchemy. > > In teoria l'idea è questa: > > - Login con schema public. > - Recupero dell'ID_SCHEMA dal record dell'utente. > - SET SEARCH_PATH con ID_SCHEMA, public; > - Resto delle query. >
Ricorda che PostgreSQL è statefull, mentre HTTP è stateless. La cosa non può funzionare a meno di non avere una connessione dedicata per ciascun utente. Magari si può anche fare, ma a questo punto meglio avere 170 database usando un template di base per la creazione. > Per impostare lo schema utilizzo l'evento checkout dei *Connection Pool > Events* > @event.listens_for(Pool, 'checkout') > Che tipo di Pool usi? > Per le sessioni database di sqlalchemy utilizzo una stipida classe singleton > che usa scoped_session. > Nell'evento *checkout* uso django-crequest per recuperare le informazioni > per l'utente della request corrente. > > La cosa sembra funzionare, ma quando provo a lanciare tipo un centinaio di > client paralleli comincia a darmi degli errori, apparentemente casuali, che > vanno dal *cursor already closed* a *too many clients already* > Il primo significa che hai un *serio* problema di accesso alla connessione. Il secondo probabilmente è PostgreSQL che si lamenta (giustamente) di troppe connessioni. > Come potrei evitare questi errori o altri non ancora visti? > Sto facendo la cosa in maniera corretta? > Quanto legno potrebbe sgranocchiare una marmotta se una marmotta potesse > sgranocchiare legno? > > notte > Ciao Manlio > -- > Luca > > _______________________________________________ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python > _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python