> > > Non credo sia quello che intenda, vedi > http://martinfowler.com/eaaCatalog/unitOfWork.html
In merito al tuo link: << A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work.>> decorando esecuzione della mia logica con @transaction.atomic non ottengo esattamente questo, un po' come la creazione di un'unica transazione con flush\commit finale in sqlalchemy? Forse mi sfugge il punto... > > 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 il punto è questo allora mi piace la soluzione proposta da te! Mi è già capitato di cachare oggetti da utilizzare spesso: penso allo states pattern e al caching degli oggetti di stato. In tal caso me la gestirei così, tenendo pero' in cache solo -appunto- gli oggetti base di stato (per non doverli reinstanziare ogni volta, specie se gli stati sono molti) e lasciando che la transazione evolva in uno stato di rollback se qualcosa dovesse andare male
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
