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?
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?
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: Application instance at 2a9e91f9e0 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?
Jeff Gentry wrote at 2006-1-20 17:14 -0500: ... What I saw was that 'B' would say: B instance at 2a9e9274e0 (or some other mem address) while 'C' would say: C instance at /gg/some/path 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: 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 )
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: B instance at 2a9d564da0 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 (SimpleItems, 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?
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?
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 (SimpleItems, 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: B instance at 2a9e9274e0 (or some other mem address) while 'C' would say: C instance at /gg/some/path 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?
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: B instance at 2a9e9274e0 (or some other mem address) while 'C' would say: C instance at /gg/some/path 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: Application instance at 2a9e91f9e0 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?
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 )
[Zope] Class instances changing address?
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 source of the problem. 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: B instance at 2a9d564da0 What I found was at the moment that things stopped working, the address of the instance was changed, which explains a lot. However, I can not figure out why this would happen - as far as I can tell the B instance is not being reassigned in any capacity in my code. Also, this seems to happen a bit nondeterministically (although I'm sure it isn't really) in that the same set of operations will not always have the same result here - it might cause the above switch/failure in one run through but not the next 3 times. 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 :( 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). Thanks in advance Jeff ___ 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 )
