Message: 2
Date: Wed, 24 Jul 2002 13:05:59 -0700
To: "Matthew T.
Kromer" <
matt@zope.com>
Cc: Ross
Boylan <
RossBoylan@stanfordalumni.org>,
zope-dev@zope.orgSubject: Re:
[Zope-dev] Refresh trashes acquisition
From: Ross Boylan <
RossBoylan@stanfordalumni.org>
On
Wed, Jul 24, 2002 at 10:38:44AM -0400, Matthew T. Kromer wrote:
> Ross
Boylan wrote:
>
> >I find that when I refresh my product it
destroys some of the
> >containment relationships. Things start
failing, and as far as I can
> >tell the only recovery is to completely
rebuild the object.
> >
> >This is a big problem, and if
anyone could explain what is going on
> >and how to avoid it I would
appreciate it.
> >
> >Here is the result of aq_chain before
the refresh:
> >[<RankQuestion instance at 8dd5620>,
>
><OriginalSuborder instance at 8c9f8d8>, <EMailBallot instance
at
> >8dfc870>, <__FactoryDispatcher__ instance at
8e73770>,
> ><ProductDispatcher instance at 83f0618>,
<Folder instance at 8d5733
> >
> >and after
>
>[<RankQuestion instance at 8dee2d0>]
> >
>
>
> [...]
>
> >
> >
>
> Hmm,
while what you're referring to is "refresh" in the sense of a
> product
reload, it's important to first state that *no* acquisition is
> expected
to survive between transactions.
>
> Each transaction must
separately acquire its objects; if you try to pass
> wrapped objects
between transactions or threads you're going to end up
> in
trouble.
>
> Secondly, when a product is refreshed, the
extensionclass module will
> probably create new base classes for any
ExtensionClass derived class
> file. I dont *think* you can get
much mileage out of knowing the id
> (address) of a class now, but be
aware that a refresh will likely cause
> that address to change. I
have seen some bizarre errors where module
> "constants" changed because
of a reload, and "is" tests broke because
> "is" tests the object
address.
>
> None of this is explicitly what you're asking about --
but I think what
> you're trying to do is in violation of the "no wrapped
objects should be
> stored past a transaction boundary" rule.
>
> However, I may be misreading your question too -- which is why I
mention
> those two rules above so YOU can see if they make sense in your
context.
>
The first point is definitely relevant, and explains
why I am having
problems. It's surprising what I'm doing is workign at
all! The
class redefinition in the second point might explain some of
the
timing of the problems, but it's the instances, not the classes that
I
am interested in.
The acquisition I want to do is in the object
containment hierarchy,
but URL of the request will also have this
hieararchy. Is
there some way I can grab it at the appropriate
time?
Your comments also clarify a point that was unclear to me from
the
documentation on acquisition. The documents refers to the
object
containment hierarchy and the request path hierarchy, and
recommend
keeping them consistent. But I didn't understand which
hierarchy it
used if they weren't. Apparently only the request path
matters.
It may be helpful to say more about the exact relations in my
case:
[indentation indicates containment in this diagram; capital
letters
are for objects]
B ballot
Q1
question
R1a response
R1b
response
SR suborder of
responses
see below for
suborders
R1a
R1b (same
objects as the R1's above)
Q2 question ...
NQ
"namestyle" of questions (determines labeling)
NR namestyle of
responses
SQ suborder of questions (sequential, random,
...)
this suborder contains a list of the same questions Q1, Q2,
etc
that the ballot B holds.
It also the name of
the namestyle, to be acquired from the container.
Generally, B and maybe Q
will be in my request path, and the other
items are not.
I ask the
suborders for list of items, so they give me back a list of
Q's or R's.
The items in those lists were the ones I was trying to
wrap.
At the
most extreme case, I get a response R from the suborder list of
a question Q,
and I get the Q from the suborder of the ballot. So I't
two levels
removed from my original context, the ballot B, that has
the namestyle I'm
trying to acquire. The suborder on the Question
needs to acquire the
namestyle from the Ballot.
Finally, I may be making an overly
conservative assumption about
ObjectManagers. Without it, the suborders
would not need to hold onto
object references. It's easiest to explain
this with a specific
example. I want to be able to recover the original
order questions
were entered into the ballot. Ballot is a subclass of
ObjectManager.
I believe I am not allowed to make any assumptions about the
order
its items will be returned by objectItems(), so I am using
the
suborder to track that.
P.S. I also assume that
objectItems('type') gets only objects of that
type, not subtypes. Does
anyone know if that's
so?
--__--__--
_______________________________________________
Zope-Dev
maillist -
Zope-Dev@zope.orghttp://lists.zope.org/mailman/listinfo/zope-dev(To
receive general Zope announcements, see:
http://lists.zope.org/mailman/listinfo/zope-announceFor
non-developer, user-level issues,
zope@zope.org,
http://lists.zope.org/mailman/listinfo/zope
)
End of Zope-Dev Digest