<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Non credo sia quello che intenda, vedi <a href="http://martinfowler.com/eaaCatalog/unitOfWork.html" rel="noreferrer" target="_blank">http://martinfowler.com/eaaCatalog/unitOfWork.html</a></blockquote><div><br></div><div><div>In merito al tuo link: <br><br><< 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.>><br><br> 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...</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Il punto credo sia business transaction vs database transaction, tenendo pure presente di gestire una business transactions che dura per più di una request.<br><br></blockquote><div><br></div><div>Se il punto è questo allora mi piace la soluzione proposta da te!<br>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</div></div></div></div>