Re: [Zope] Class instances changing address?
On 1/23/06, Chris Withers <[EMAIL PROTECTED]> wrote: > > - Never store a reference to a persistent object inside a non-persistent > > object. > > I don't think this is a useful warning. Unless you expect to retrieve it after a server restart. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
Gabriel Genellina wrote: - Never store a reference to a persistent object inside another persistent object; use its id or path to retrieve it when needed. I suspect storing the aq_base of an object will mitigate any problems you have here... - Never store a reference to a persistent object inside a non-persistent object. I don't think this is a useful warning. - If a persistent object "owns" some other persistent objects, make the first an ObjectManager. ...and this is bordering on rubbish ;-) - Let Zope manage transactions, and avoid bare try/excepts Aha, now this is a good one :-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
Jeff Gentry wrote at 2006-1-20 17:14 -0500: > ... >What I saw was that 'B' would say: > (or some other mem address) >while 'C' would say: > Thus, "B" is not wrapped while "C" is. >My knowledge of these things is poor but that would imply that B is not >properly wrapped? FWIW when I instantiate 'B' I do a _setObject() and >then a _getOb() and use the return value from that, my understanding being >that this is what wraps the object. Indeed. But the "B" above did not take this route... > ... >> Do you use "try: ... except: ..." and swallow valuable exception >> information? > >It isn't clear to me what to except on. You should not. The question was just a safeguard that essential information were not lost due to a bad "try: ... except: ...". -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
Jeff Gentry wrote at 2006-1-20 18:07 -0500: > ... >Looking at this, as well as absolute_url_path and watching the result of >SQLConnectionIDs() it appears that the problematic instance is actually >the instance of class 'A'. When the problem I'm seeing occurs, the >aq_parent of 'A' changes, eg: > >will be changed to another address. >(It is in the root folder of the ZMI). The address will be different when you happen to look in a different connection (each connection has its own copies of the persistent objects; therefore, their address differ). Nevertheless, the persistent state should look identical. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
At Friday 20/1/2006 20:07, Jeff Gentry wrote: As background, the primary class (A) maintains a handle to an instance of another class (B) which handles interaction w/ a psycopg db controller. Class A also will instantiate several instances of Class C and as part of the construction will pass it the handle to class B. So in summary, A has a B and has 1:n C's, and C has a reference to B. A & B have physical representations in the ZMI, while instances of C are 'virtual'. If you follow these rules you should be safe: - Never store a reference to a persistent object inside another persistent object; use its id or path to retrieve it when needed. - Never store a reference to a persistent object inside a non-persistent object. - If a persistent object "owns" some other persistent objects, make the first an ObjectManager. - Let Zope manage transactions, and avoid bare try/excepts Of course you can break the rules if you really really know what you are doing but they are a good starting point. And reading about how persistence works is a big help (it appears you've already read it, I think). Gabriel Genellina Softlab SRL ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
Sorry for the self followup, but some update info. On Fri, 20 Jan 2006, Jeff Gentry wrote: > running through the system looking at the repr() of these instances (both > 'B' and 'C'). What I saw was that 'B' would say: > (or some other mem address) > while 'C' would say: > Looking at this, as well as absolute_url_path and watching the result of SQLConnectionIDs() it appears that the problematic instance is actually the instance of class 'A'. When the problem I'm seeing occurs, the aq_parent of 'A' changes, eg: will be changed to another address. (It is in the root folder of the ZMI). I don't see any clear spots where I might be changing the parent of the 'A' object, although it is certainly possible via side effect. Particularly confusing is the seemingly nondeterministic behavior on when this happens although I'm assuming it was due to the threading issues mentioned earlier in this particular thread? Thanks -J ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
On Fri, 20 Jan 2006, Dieter Maurer wrote:
> Your "B instance" above, is apparently not acquisition wrapped.
> Acquisition wrapped instances usually include the container path
> in their "repr" (if the intermediate objects have an id/getId --
> this is the case of instances with "ZMI representation" ("SimpleItem"s,
> to be precise).
This seems like a likely culprit, although on the surface I thought I was
wrapping 'B'. Based on another comment I tried reimplementing the system
so that instances of 'C' also had a ZMI representation, and I started
running through the system looking at the repr() of these instances (both
'B' and 'C'). What I saw was that 'B' would say:
(or some other mem address)
while 'C' would say:
My knowledge of these things is poor but that would imply that B is not
properly wrapped? FWIW when I instantiate 'B' I do a _setObject() and
then a _getOb() and use the return value from that, my understanding being
that this is what wraps the object.
> Does your logfile contains unexplained entries?
No, unfortunately.
> Do you use "try: ... except: ..." and swallow valuable exception
> information?
It isn't clear to me what to except on. The error that gets thrown
doesn't appear to be a normal Zope error (e.g. AttributeError,
ProgrammingError, etc), it just says (in italics) something along the
lines of 'Psycopg_database_controller cannot be found' w/o traceback info,
etc.
Thanks
-J
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
On Fri, 20 Jan 2006, Chris Withers wrote: > I'm afraid that what you need to do is get as small as possible an > example that reproduces the problem by hacking out lots of your code > until the problem stops occuring. Doing this usually helps me fix the > problem, but if not, you can at least post the answer here ;-) Yeah, I recognize the value in doing that and I will try this weekend. It is just unclear to me how to easily construct a mini-example at the moment for this particular situation. > - Do any of your attribute names start with _v_ ? No, although that would explain it if I did. > - You may be running into problems with Acquisition and differing > acquisition contexts... The three responses I received all touched on this issue to some extent, as well as issues such as the Persistence mechanisms, etc. I've been pretty in the dark as to how a lot of that works so hopefully reading up on these will shed some light as to what I'm doing wrong. Thanks -J ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
Jeff Gentry wrote at 2006-1-19 16:55 -0500:
> ...
>As background, the primary class (A) maintains a handle to an instance of
>another class (B) which handles interaction w/ a psycopg db
>controller. Class A also will instantiate several instances of Class C
>and as part of the construction will pass it the handle to class B. So in
>summary, A has a B and has 1:n C's, and C has a reference to B. A & B
>have physical representations in the ZMI, while instances of C are
>'virtual'.
>
>What is happening at times is that all of a sudden any call from C to B
>(ie C is accessing the DB) will result in Zope reporting that it could not
>find the psycopg controller, and indeed when this happens, any call
>through B via C will show that B can not find any DB controllers (using
>SQLConnectionIDs()). When I looked a bit closer, I had C's instance of B
>do a 'print instanceOfB' before calling out to B, which looked like this
>in the console:
>
>
>What I found was at the moment that things stopped working, the address of
>the instance was changed, which explains a lot.
No object in Python can ever change its address.
If you observe a "c.b" changing address, then this means that either
* you look at a different "c"
* a new value was assigned to "c.b" (by an explicit assignment
and not be magic -- unless something skrewed the memory
management).
Your "B instance" above, is apparently not acquisition wrapped.
Acquisition wrapped instances usually include the container path
in their "repr" (if the intermediate objects have an id/getId --
this is the case of instances with "ZMI representation" ("SimpleItem"s,
to be precise).
> However, I can not figure
>out why this would happen
Does your logfile contains unexplained entries?
Do you use "try: ... except: ..." and swallow valuable exception
information?
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Class instances changing address?
Jeff Gentry wrote: I wish I could post some relevent code but the code base but given that I'm not at all sure what section of the code might be causing this and the code base is several thousand lines long, that'sn ot really possible :( I'm afraid that what you need to do is get as small as possible an example that reproduces the problem by hacking out lots of your code until the problem stops occuring. Doing this usually helps me fix the problem, but if not, you can at least post the answer here ;-) What I was hoping was that people might have some ideas as to what I might be doing wrong here (and admittedly I tought myself Zope & Python mostly from other Zope products and trial & error so there might be some key issue that I'm totally missing). - Do any of your attribute names start with _v_ ? - You may be running into problems with Acquisition and differing acquisition contexts... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
