On Aug 23, 2009, at 4:03 AM, Alexander Lebedev wrote:
> Great thanks for the answer. > > But if these object are already in my session? For example, I create > a query, get some related objects from the query. Then the user > modifies all objects, but he decides to save only one object, while > remaining objects must be changed (user may decide to save this > changes later, after some minutes, or he may decide cancel the > changes for unsaved objects). What can I do in this situation? the Session and the objects attached to it essentially represent a live conversation with a transaction. if you have some kind of GUI application with many elements that can be saved distinctly, I'd leave them out of a session during use (they can be removed with expunge()), or you can use a separate Session that is just for "persist" operations - if the model you're seeking is that of, "user wants to save - open a new transaction, save object, commit transaction", I might use merge() on the second session to merge the given state with what's currently in the database - that at least allows your orginal object to stay in its original session, although you might want to refresh the original session if new state has been persisted from a concurrent transaction. You should consider the effects of concurrent transactions in your application, i.e. if the user has an object on his screen for five minutes and in that time someone else commits changes, how would you like to deal with that ? etc. another method which might be more appropriate is one Session per "thing the user wants to save". Such as if I had three windows open, each with a "save" button, I'd use a distinct Session for each window. this might be more appropriate depending on what you're doing. again its a question of how you want the objects to interact within a transaction (or not). yet another way would be to have the state of the GUI represented by a different set of objects entirely, which "proxy" their state to an ORM mapped and session-bound object at the point at which they want to persist their state. this requires some more complex construction up front but would probably be very easy to use after that point. --~--~---------~--~----~------------~-------~--~----~ 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 sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
