On Friday, March 13, 2015 at 7:13:52 AM UTC-4, Niphlod wrote: > > >> Why would you need a commit()? If everything is happening within a web2py >> request, any open transactions will be rolled back should either database >> throw an error, or if the app code itself results in an exception. So, if a >> record in one database is deleted, but then an exception occurs before the >> linked record in the other database is deleted, the initial delete gets >> rolled back. >> >> > Still not convinced. if you don't commit() before you don't know what is > going wrong, and you must be sure that the only operation going wrong is > updating the two databases at the same time. >
Is the concern that the commit operation of the second transaction will itself raise an exception (at which point, the first transaction has already been commited)? Aside from that possibility, wouldn't any error (within the databases or otherwise) simply result in both transactions being rolled back? I'm not saying this is as good as having everything in one database, but if you *have to* have two databases, you have to manage this via the framework/app code somehow. What else would you suggest? Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
