Re: [Zope] Class instances changing address?

2006-01-23 Thread Lennart Regebro
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/

Re: [Zope] Class instances changing address?

2006-01-23 Thread Chris Withers
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 i

Re: [Zope] Class instances changing address?

2006-01-22 Thread Dieter Maurer
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 '

Re: [Zope] Class instances changing address?

2006-01-22 Thread Dieter Maurer
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: >

Re: [Zope] Class instances changing address?

2006-01-20 Thread Gabriel Genellina
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

Re: [Zope] Class instances changing address?

2006-01-20 Thread Jeff Gentry
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

Re: [Zope] Class instances changing address?

2006-01-20 Thread Jeff Gentry
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"

Re: [Zope] Class instances changing address?

2006-01-20 Thread Jeff Gentry
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 po

Re: [Zope] Class instances changing address?

2006-01-20 Thread Dieter Maurer
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 pa

Re: [Zope] Class instances changing address?

2006-01-20 Thread Chris Withers
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 po

[Zope] Class instances changing address?

2006-01-19 Thread Jeff Gentry
Hello ... I'm running Zope 2.7.3 w/ python 2.4.1. I'm in the process of developing a FS based product as a primary class w/ many sub-classes. I've been experiencing a problem which I thought I had completely nixed but apparently only partly so and now am out of ideas as to what might be the sour