2015-09-19 12:13 GMT+02:00 Riccardo Magliocchetti < riccardo.magliocche...@gmail.com>:
> 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/ > > Avevo letto questo articolo, ma troppo tempo fa e non lo ricordavo più. > Non credo sia quello che intenda, vedi > http://martinfowler.com/eaaCatalog/unitOfWork.html Intendevo esattamente questo, forse avrei dovuto aggiungere un pò di contesto :) > > Il punto credo sia business transaction vs database transaction, tenendo > pure presente di gestire una business transactions che dura per più di una > request. > Introdurre una business transaction mi aiuterebbe a semplificare molto la domain logic e mi sono accorto che proprio non ho bene idea di come fare. Non ho cmq la pretesa che una transaction duri più di una request, o almeno per ora non ne vedo l'utilità nel mio caso. > > 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. > Hai ragione, può essere un delirio. eppure credo che il pattern sia utile e non capisco perchè nessuno nel mondo python abbia avanzato una soluzione, non trovo altro che esempi per LINQ :D > > Qua ci sono diversi possibili spunti: > http://stackoverflow.com/questions/6245498/django-orm-unit-of-work > > Grazie!
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
