[Zope] Persistence Problem

Charlie Reiman creiman@kefta.com
Fri, 16 Aug 2002 09:52:32 -0700


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 )
> >
>
>