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
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
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:
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
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
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
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
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
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
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
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
11 matches
Mail list logo
