Il 19/09/2015 11:29, flandero ha scritto:
2015-09-17 10:44 GMT+02:00 Stefano Bossi <ste.bo...@gmail.com <mailto:ste.bo...@gmail.com>>:Qualcuno l'ha mai implementato? A parte l'implementazione di SQLAlchemy ne conoscete altre? Sapete per caso se Django non lo ha mai preso in considerazione?
Direi di no by design: http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/
Ciao, forse ti riferisci a: Forse ti riferisci a https://docs.djangoproject.com/en/1.8/topics/db/transactions/, precisamente al metodo 'atomic' atomic(/using=None/, /savepoint=True/)[source] <https://docs.djangoproject.com/en/1.8/_modules/django/db/transaction/#atomic>¶ <https://docs.djangoproject.com/en/1.8/topics/db/transactions/#django.db.transaction.atomic> Atomicity is the defining property of database transactions. atomic allows us to create a block of code within which the atomicity on the database is guaranteed. If the block of code is successfully completed, the changes are committed to the database. If there is an exception, the changes are rolled back.
Non credo sia quello che intenda, vedi http://martinfowler.com/eaaCatalog/unitOfWork.html Il punto credo sia business transaction vs database transaction, tenendo pure presente di gestire una business transactions che dura per più di una request.
Se dovessi farlo mi serializzerei le operazioni che vorrei fare su una cache e alla fine della fiera, deserializzo e faccio tutto in un blocco. Fare l'eventuale merge delle operazioni ridondanti lo vedo già più complicato. Poi c'è anche da pensare a come invalidare unit of work presenti in cache ma non completate. Molto probabilmente farei una cosa che, se funziona, funziona per miracolo.
Qua ci sono diversi possibili spunti: http://stackoverflow.com/questions/6245498/django-orm-unit-of-work -- Riccardo Magliocchetti @rmistaken http://menodizero.it _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
