I'm storing database connections, not simple objects (not even Zope objects). My DA has to store them, or at least have easy access to them. If you want the longer story... I'm implementing user keyed connections with exUserFolder and DCOracle2. The way it works is a user signs on with a id and password, which exUserFolder will then use to attempt to hook up to a database via DCO2. If it succeed, the user is considered authenticated and the connection is cached under DCO2 for future use. All future DCO2 transactions for that user funnel through her private connection. I know Zope DAs are not designed to do this (trust me, no one knows this more than me right now). It's way too complicated and an evolutionary dead end but my boss really wants it, so he gets it.
-----Original Message----- From: Chris McDonough [mailto:chrism@zope.com] Sent: Friday, August 16, 2002 9:36 AM To: Charlie Reiman; kthangavelu@earthlink.net; zope@zope.org Subject: Re: [Zope] Persistence Problem
I forget the geneology of this thread, but what was wrong with storing the data in a session?
----- Original Message ----- From: "Charlie Reiman" <creiman@kefta.com> To: <kthangavelu@earthlink.net>; <zope@zope.org> Sent: Friday, August 16, 2002 12:34 PM Subject: RE: [Zope] Persistence Problem
Thanks everyone. This dawned on me as I was on the train riding home. I also found __setstate__ and __getstate__ if I want to mess with the loading hooks (I don't).
http://www.zopelabs.com/cookbook/1002251996
The Zope Developer's guide does talk about module variables. But all it says is:
"Objects stored in modules but not in the ZODB are not persistent and not-thread safe. In general it's not a good idea to store data (as opposed to functions, and class definitions) in modules when using ZODB."
This is not helpful, as there are times when this level of storage is exactly what you want. This paragraph reads as a "Just don't do this," paragraph rather than a "You can do this, here's why you'd want to and what pitfalls to avoid," paragraph. I've seen the same trick in exUserFolder (although I did not understand why it did that until yesterday).
Also, the dev guide makes no mention of _v_ attributes be thread/connection specific, which is a dangerous oversight, IMHO.
I've made the appropriate comments to the dev guide online. Thanks for everyone's help.
Charlie.
-----Original Message----- From: kapil thangavelu [mailto:kthangavelu@earthlink.net] Sent: Thursday, August 15, 2002 7:43 PM To: Charlie Reiman; zope@zope.org Subject: Re: [Zope] Persistence Problem
as andy mentioned, _v_ volatile attributes are specific to a thread (well, technically there specific to the underlying zodb connection). they remain only as long as the object remains in memory/cache.
.......
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )