Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#8 should guard against pickle errors

closed-fixed
nobody
None
3
2003-01-15
2001-12-12
Geoff Talvola
No

SessionStore should protect against pickling
errors.

When it's saving a session to disk, it should
first pickle to a string, then write the pickle out
to a file. This two-step process ensures that if
a pickling exception occurs, the file is not
corrupted.

And when it's reading in a session from disk,
it should probably trap unpickling errors and
transform them into KeyErrors.

(Thanks to Ken Lalonde for pointing this out.)

Discussion

  • Logged In: YES
    user_id=326269

    This was resolved along with handling patch [ 630505 ] Store
    session pickle error handling

    This will be present in the 0.8 release.

     
    • status: open --> closed-fixed
     
  • Logged In: YES
    user_id=23678

    Should there be some way to validate the current session, so
    it does not contain any unpickable object? In this 'safe'
    mode, a warning would be issued whenever something
    unpickable (a db session, for example) is assigned to the
    session. It would be a kind of bounds-checking option that
    could be turned off for speed.

     
  • Logged In: YES
    user_id=326269

    It seems like unpicklable data is a developer only issue and
    should be caught in development.

    Try saving a session to disk (ie: shutting down the
    AppServer) and the sessions will get saved to disk.

    If data can't be saved because it is unpicklable then you'll
    get the error.

    I'm not sure how a run-time validation would be much more
    useful. I suppose you could do a very friendly validation
    that would walk the object and check each property, but
    again I am not sure if it is worth it in this case.

    Maybe I'm just fully understanding what the benefits might be.

     
  • Logged In: YES
    user_id=23678

    This mode I am talking about would be helpful to the
    programmer. It only makes the process you described (dumping
    the session to disk, or at least to a string) automatic. It
    is just a question of passive error check against active
    error check (shutting the application down). The sooner you
    get the error (as soon as you make the incorrect assignment,
    not after several minutes) the softer the correction is. In
    a long running application, sessions don't get pickled as
    often, so it is easy to overview mistakes of this kind.

    Please let me know if I did not make myself clear.