Hey there, On 6/8/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > > SA Sessions handle unit of work, each instance of a db-mapped object > > is tied to a session which handles its state (new, dirty etc.). SA 0.2 > > allows the user to handle session explicitly, but the threadlocal mod > > restores 0.1 behaviour - where there's basically an implicit > > per-thread session. > > Thinking about this more properly now, I actually don't think it makes > a big difference. TG can automatically get a session and hang on to it > per request, or we can use the threadlocal. It'll wind up in a > threadlocal somewhere. > > There's a certain appeal to having TG do it, since we would, > theoretically, know where the session boundaries are (since we already > do the same kind of thing with SQLObject transactions).
I agree. In my patch, the session boundaries are where they are with SQLobject (and SA 0.1) - in run_with_transaction. The session exist before and after that though, it's just clear()'d before running the controller and flush()'d or close()'d afterwards. My initial idea was to write a cp-filter that established a session at the beginning of the request and closed it at the end. This would require users to explicitly add new objects to this session if they wanted them to be inserted into the db. Also, I wasn't sure how/where to store it and how to access it from the identity/visit stuff - mostly because I'm not sure when in the request-process that code is called in TG. SA 0.2 provides a more general version of this "default session" mechanism. I haven't studied it carefully, but as I under stand it you (we? :o) just supply a function that returns a hashable key depending on context (for example some request-id). SA then manages a default session based on that key. By using that, you can make the default session request-local, window-local, user-local or "whatever context"-local, instead of thread-local. At least this is my understanding. Maybe that will be of use? Are there any use cases where a user might spawn a second thread during a request - is that even possible with CP? Arnar --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
