On Thursday, February 4, 2016 at 9:36:43 AM UTC-5, Michael Bayer wrote:
You might find it a better approach overall to use a separate Session > for persistence, have your users deal with entirely detached objects and > then just copy their state to the Session when you're ready to persist > them, using merge() or something homegrown. I'm assuming the desire to not have long transactions is because you have multiple concurrent users. if that's the case, you'll always run into issues with a ORM (sqlalchemy or not). Personally, I would track changes into a `dict` (instead the ORM objects) and on "Save" I would start a transaction and copy the data over. I'd also track a "revision id" or "revision timestamp" on each object , and use that as a comparison to ensure that any operations happen on the same revision. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
