That's exactly what my fix does, it makes session.save() be deferred by setting a flag to perform the actual save at the end of the request in the session middleware. You still need to call session.save() at least once to make sure the session will be saved, so up upside of all this is that people don't need to modify their code to take advantage of this single deferred save design. And now you don't have to be afraid to add session.save() calls as they will not cause any unnecessary saves.....
On Jan 7, 10:25 pm, "Mike Orr" <[email protected]> wrote: > On Wed, Jan 7, 2009 at 10:16 AM, Ben Bangert <[email protected]> wrote: > > On Jan 7, 2009, at 4:59 AM, Paweł Stradomski wrote: > > >> Just note, that in case the dict is not modified directly, but an object > >> inside is modified, you won't get notified of the change. > > >> Eg. suppose the restored session has: > >> session['messages'] = [] > > >> Now i do: > >> session['messages'].append(u'New flash message') > > >> You won't see that the session has changed. > > > This is the exact reason we don't have a 'dirty' type flag like this set on > > setitem. However, I think it'd be useful to let a user set the 'dirty' flag > > themselves, in addition to letting sessions auto-save merely upon access > > (just to be sure), or something as Tycon suggests. Many people end up > > calling save() multiple times because they need to put stuff in the session > > in various places and ensures its saved, when really, they should be marking > > it 'to-be-saved' so its done just *once*. > > Ideally session.save() should really mean mark-to-save, and the actual > saving done at the end of the request. The issue is that a generic > function may modify the session (as is the case with Flash), and it > does not know whether the caller will call .save or not. Likewise, > the caller may not even know that the function is using the session. > > I do like the session.save() step because it acts like a transaction > commit, explicity confirming that the session is to be modified > persistently. On the other hand, it's not truly like a transaction > because there is only one session, and any call to .save() will cause > all changes to be saved, even if they were made in functions that did > not themselves call .save(). But in practice, nobody modifies the > session and leaves undesired changes in it counting on them being > rolled back, so it's more of a theoretical problem than an actual > problem. > > -- > Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
