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
-~----------~----~----~----~------~----~------~--~---
