[Zope-dev] Refresh trashes acquisition
Gary Speer
gspeer@cortech.org
Thu, 25 Jul 2002 12:09:35 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_000E_01C233D4.24686560
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Dear Ross -=20
I strongly encourage you to switch to the zope@zope.org mailing list as =
this one is dedicated to next-generation product enhancement as opposed =
to peer user assistance.
The approach you are taking seems a bit convoluted and I, for one, do =
not understand the business/project objectives reason to construct the =
objects as you do and create the acquisition cvhallenge you hope to =
solve. Perhaps you can elaborate on the goal you hope to accomplish so =
others can suggest the better tools and object containment structure to =
use. It seems earlier design decisions have taken you to solving issues =
that might not exist with an alternative, more-naturally-zope-like =
approach.
Gary
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.org
Subject: 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:
>=20
> >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>]
> >=20
> >
> [...]
>=20
> >=20
> >
>=20
> Hmm, while what you're referring to is "refresh" in the sense of a=20
> product reload, it's important to first state that *no* acquisition is =
> expected to survive between transactions.
>=20
> Each transaction must separately acquire its objects; if you try to =
pass=20
> wrapped objects between transactions or threads you're going to end up =
> in trouble.
>=20
> Secondly, when a product is refreshed, the extensionclass module will=20
> probably create new base classes for any ExtensionClass derived class=20
> file. I dont *think* you can get much mileage out of knowing the id=20
> (address) of a class now, but be aware that a refresh will likely =
cause=20
> that address to change. I have seen some bizarre errors where module=20
> "constants" changed because of a reload, and "is" tests broke because=20
> "is" tests the object address.
>=20
> None of this is explicitly what you're asking about -- but I think =
what=20
> you're trying to do is in violation of the "no wrapped objects should =
be=20
> stored past a transaction boundary" rule.
>=20
> However, I may be misreading your question too -- which is why I =
mention=20
> those two rules above so YOU can see if they make sense in your =
context.
>=20
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.org
http://lists.zope.org/mailman/listinfo/zope-dev
(To receive general Zope announcements, see:
http://lists.zope.org/mailman/listinfo/zope-announce
For non-developer, user-level issues,=20
zope@zope.org, http://lists.zope.org/mailman/listinfo/zope )
End of Zope-Dev Digest
------=_NextPart_000_000E_01C233D4.24686560
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dear Ross - </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I strongly encourage you to switch to =
the <A=20
href=3D"mailto:zope@zope.org">zope@zope.org</A> mailing list as this one =
is=20
dedicated to next-generation product enhancement as opposed to peer user =
assistance.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The approach you are taking seems a bit =
convoluted=20
and I, for one, do not understand the business/project =
objectives reason to=20
construct the objects as you do and create the acquisition cvhallenge =
you hope=20
to solve. Perhaps you can elaborate on the goal you hope to =
accomplish so=20
others can suggest the better tools and object containment structure to=20
use. It seems earlier design decisions have taken you to solving =
issues=20
that might not exist with an alternative, more-naturally-zope-like=20
approach.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Gary</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>Message: 2<BR>Date: Wed, 24 Jul 2002 13:05:59 -0700<BR>To: "Matthew =
T.=20
Kromer" <<A =
href=3D"mailto:matt@zope.com">matt@zope.com</A>><BR>Cc: Ross=20
Boylan <<A=20
href=3D"mailto:RossBoylan@stanfordalumni.org">RossBoylan@stanfordalumni.o=
rg</A>>,=20
<A href=3D"mailto:zope-dev@zope.org">zope-dev@zope.org</A><BR>Subject: =
Re:=20
[Zope-dev] Refresh trashes acquisition<BR>From: Ross Boylan <<A=20
href=3D"mailto:RossBoylan@stanfordalumni.org">RossBoylan@stanfordalumni.o=
rg</A>><BR><BR>On=20
Wed, Jul 24, 2002 at 10:38:44AM -0400, Matthew T. Kromer wrote:<BR>> =
Ross=20
Boylan wrote:<BR>> <BR>> >I find that when I refresh my product =
it=20
destroys some of the<BR>> >containment relationships. Things =
start=20
failing, and as far as I can<BR>> >tell the only recovery is to =
completely=20
rebuild the object.<BR>> ><BR>> >This is a big problem, and =
if=20
anyone could explain what is going on<BR>> >and how to avoid it I =
would=20
appreciate it.<BR>> ><BR>> >Here is the result of aq_chain =
before=20
the refresh:<BR>> >[<RankQuestion instance at =
8dd5620>,<BR>>=20
><OriginalSuborder instance at 8c9f8d8>, <EMailBallot =
instance=20
at<BR>> >8dfc870>, <__FactoryDispatcher__ instance at=20
8e73770>,<BR>> ><ProductDispatcher instance at 83f0618>,=20
<Folder instance at 8d5733<BR>> ><BR>> >and after<BR>> =
>[<RankQuestion instance at 8dee2d0>]<BR>> > <BR>>=20
><BR>> [...]<BR>> <BR>> > <BR>> ><BR>> <BR>> =
Hmm,=20
while what you're referring to is "refresh" in the sense of a <BR>> =
product=20
reload, it's important to first state that *no* acquisition is <BR>> =
expected=20
to survive between transactions.<BR>> <BR>> Each transaction must=20
separately acquire its objects; if you try to pass <BR>> wrapped =
objects=20
between transactions or threads you're going to end up <BR>> in=20
trouble.<BR>> <BR>> Secondly, when a product is refreshed, the=20
extensionclass module will <BR>> probably create new base classes for =
any=20
ExtensionClass derived class <BR>> file. I dont *think* you can =
get=20
much mileage out of knowing the id <BR>> (address) of a class now, =
but be=20
aware that a refresh will likely cause <BR>> that address to =
change. I=20
have seen some bizarre errors where module <BR>> "constants" changed =
because=20
of a reload, and "is" tests broke because <BR>> "is" tests the object =
address.<BR>> <BR>> None of this is explicitly what you're asking =
about --=20
but I think what <BR>> you're trying to do is in violation of the "no =
wrapped=20
objects should be <BR>> stored past a transaction boundary" =
rule.<BR>>=20
<BR>> However, I may be misreading your question too -- which is why =
I=20
mention <BR>> those two rules above so YOU can see if they make sense =
in your=20
context.<BR>> <BR><BR>The first point is definitely relevant, and =
explains=20
why I am having<BR>problems. It's surprising what I'm doing is =
workign at=20
all! The<BR>class redefinition in the second point might explain =
some of=20
the<BR>timing of the problems, but it's the instances, not the classes =
that=20
I<BR>am interested in.<BR><BR>The acquisition I want to do is in the =
object=20
containment hierarchy,<BR>but URL of the request will also have this=20
hieararchy. Is<BR>there some way I can grab it at the appropriate=20
time?<BR><BR>Your comments also clarify a point that was unclear to me =
from=20
the<BR>documentation on acquisition. The documents refers to the=20
object<BR>containment hierarchy and the request path hierarchy, and=20
recommend<BR>keeping them consistent. But I didn't understand =
which=20
hierarchy it<BR>used if they weren't. Apparently only the request =
path=20
matters.<BR><BR>It may be helpful to say more about the exact relations =
in my=20
case:<BR>[indentation indicates containment in this diagram; capital=20
letters<BR>are for objects]<BR>B ballot<BR> Q1 =20
question<BR> R1a response<BR> R1b=20
response<BR> SR suborder of=20
responses<BR> see below for=20
suborders<BR> R1a<BR> =
R1b (same=20
objects as the R1's above)<BR> Q2 question ...<BR> =
NQ =20
"namestyle" of questions (determines labeling)<BR> NR =
namestyle of=20
responses<BR> SQ suborder of questions (sequential, random,=20
...)<BR> this suborder contains a list of the same questions =
Q1, Q2,=20
etc<BR> that the ballot B holds.<BR> It also the =
name of=20
the namestyle, to be acquired from the container.<BR>Generally, B and =
maybe Q=20
will be in my request path, and the other<BR>items are not.<BR><BR>I ask =
the=20
suborders for list of items, so they give me back a list of<BR>Q's or =
R's. =20
The items in those lists were the ones I was trying =
to<BR>wrap.<BR><BR>At the=20
most extreme case, I get a response R from the suborder list of<BR>a =
question Q,=20
and I get the Q from the suborder of the ballot. So I't<BR>two =
levels=20
removed from my original context, the ballot B, that has<BR>the =
namestyle I'm=20
trying to acquire. The suborder on the Question<BR>needs to =
acquire the=20
namestyle from the Ballot.<BR><BR>Finally, I may be making an overly=20
conservative assumption about<BR>ObjectManagers. Without it, the =
suborders=20
would not need to hold onto<BR>object references. It's easiest to =
explain=20
this with a specific<BR>example. I want to be able to recover the =
original=20
order questions<BR>were entered into the ballot. Ballot is a =
subclass of=20
ObjectManager.<BR>I believe I am not allowed to make any assumptions =
about the=20
order<BR>its items will be returned by objectItems(), so I am using=20
the<BR>suborder to track that.<BR><BR>P.S. I also assume that=20
objectItems('type') gets only objects of that<BR>type, not =
subtypes. Does=20
anyone know if that's=20
so?<BR><BR><BR><BR>--__--__--<BR><BR>____________________________________=
___________<BR>Zope-Dev=20
maillist - <A=20
href=3D"mailto:Zope-Dev@zope.org">Zope-Dev@zope.org</A><BR><A=20
href=3D"http://lists.zope.org/mailman/listinfo/zope-dev">http://lists.zop=
e.org/mailman/listinfo/zope-dev</A><BR><BR>(To=20
receive general Zope announcements, see:<BR><A=20
href=3D"http://lists.zope.org/mailman/listinfo/zope-announce">http://list=
s.zope.org/mailman/listinfo/zope-announce</A><BR><BR>For=20
non-developer, user-level issues, <BR><A=20
href=3D"mailto:zope@zope.org">zope@zope.org</A>, <A=20
href=3D"http://lists.zope.org/mailman/listinfo/zope">http://lists.zope.or=
g/mailman/listinfo/zope</A>=20
)<BR><BR>End of Zope-Dev Digest</DIV></BODY></HTML>
------=_NextPart_000_000E_01C233D4.24686560--