IMO our app is same kind of thing - it has a user-editing-a-document-task/transaction which is not same thing as db- transaction; At confirmation of the editing, a db-transaction is to be open and all changes to be saved; if the db-transaction fails - e.g. someone has already edited the doc, or some constraint is not met - whatever - this does not render the user-editing-transaction failing, it just goes to previuos state of not being saved (after some message++). User has to either (modify+) confirm again, which would retry the above, or explicitly cancel.
To implement this, within current context of SA object-persistance-semantic, i'll either have to have my changes kept/copied elsewhere, like undo-cmd-stack, and reapply them to the restored-by-rollback objects, or work with non-SA objects, and copy/mirror them into SA-ones at modify-db-time. i have not decided on which one yet. i was going to use db-session per user-session. > On Jan 30, 1:55 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > > On Jan 30, 2007, at 3:27 PM, Ian wrote: > > > This happens as a result of a failed session.delete() > > > operation. The flush itself appears to be fine. If you still > > > want an example, I can whip one up. > > > > what kind of application are you writing where an exception > > occurs, and the program continues to proceed normally ? > > I have to confess that I'm using session-per-application. I hadn't > realized this was considered harmful. The application is modeled > after the document-view framework where the user loads a document, > makes some number of changes to it, then closes the document with > or without saving, so flushes occur only at the user's request. > It's not clear to me how one could easily discard the session and > create a new one in this context. Doing so would probably involve > keeping track of all the unsaved changes myself, which would be > throwing away much of the value of the session object. > > > it would be a tall order for SA to implement "atomicity" for in- > > memory datastructure operations and add quite a bit of overhead > > and complexity to all cascade operations and many others. the > > usual pattern here is that you start over again and use a new > > Session. Here's how hibernate documents its own session (which > > recall sets up the basic model we are working from): > > > > http://www.hibernate.org/hib_docs/v3/reference/en/html/ > > transactions.html#transactions-basics-issues > > > > "Never use the anti-patterns session-per-user-session or > > session-per- application (of course, there are rare exceptions to > > this rule). Note that some of the following issues might also > > appear with the recommended patterns, make sure you understand > > the implications before making a design decision:" > > > > "An exception thrown by Hibernate means you have to rollback your > > database transaction and close the Session immediately (discussed > > later in more detail). If your Session is bound to the > > application, you have to stop the application. Rolling back the > > database transaction doesn't put your business objects back into > > the state they were at the start of the transaction. This means > > the database state and the business objects do get out of sync. > > Usually this is not a problem, because exceptions are not > > recoverable and you have to start over after rollback anyway." > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
