[Python] Unit of Work in python

[Riccardo Magliocchetti]

Il 19/09/2015 11:29, flandero ha scritto:
> 2015-09-17 10:44 GMT+02:00 Stefano Bossi <ste.bossi a gmail.com
> <mailto:ste.bossi a 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