Re: [Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers
Hi, I found out, somewhat surprised, that __parent__ pointers are just disguised aq_parent pointers. The changelog entries for zope 2.12 are a bit misleading in this regard. Is there somewhere an explanation of how this works? I was quite by some of the properties. Best regards, Patrick On Tue, Mar 27, 2012 at 00:09, Patrick Gerken do3cc...@googlemail.com wrote: Hi, I have a very curious problem with relationfields, and I don't know which bugtracker to use for z3c.relationfield. So, hopefully somebody here can give me some pointers. The relations are persistent objects and the from relation is stored directly on them on the from_object. For some reason, the existing relations have from objects without __parent__ or aq_parent pointers. When I update a relation, from_object is updated with an object with __parent__ and aq_parent pointers. After restart, the pointers are gone, the attribute value is None. When I want to delete the relation target object, Plone first starts a savepoint, tries to delete the object, catches any exceptions and does a rollback. It does so to test for certain exception. After the rollback, the objects lost their __parent__ and aq_parent pointers. There was something else that felt odd. the object in from_object always returned a string representation without a path on obj.__str__(), but a string representation with a path when doing obj.__repr__() and when the object had __parent__ pointers. I noticed that, because print statements and pdb tests displayed different things. The whole thing happens in Zope 2.13 with dexterity content types. I have no idea why this could happen. Anybody has any pointers for me? Thanks and best regards, Patrick ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers
On Tue, Mar 27, 2012 at 2:53 PM, Patrick Gerken do3cc...@googlemail.com wrote: I found out, somewhat surprised, that __parent__ pointers are just disguised aq_parent pointers. Are you maybe trying to use or set __parent__ on Acquisition wrappers instead of unwrapped objects? AQ wrappers have various attributes, among those aq_parent and __parent__ being the same thing. If you store an actual __parent__ attribute on a real object, you should make sure to not wrap it in an Acquisition context or explicitly unwrap it before we Acquisition.aq_base(obj). You might need some compatibility code for Zope 3 libraries, to introduce aq_base calls in the right places. On any one object, you use either parent pointers to real persistent objects, or you use Acquisition. Zope 2.12 has not introduced anything to actually store pointers to real objects. It just provides forward compatibility, so objects that do have those pointers, can avoid using Acquisition. And all of that while keeping the Acquisition API's like from Acquisition import aq_parent, aq_get) intact and working for both types of approaches. Or well, this is a bit of a lie, Zope 2.12 actually did change things for browser views, so those don't inherit from Acquisition anymore, but with those view.__parent__ is just the same as view.context - so it's easier. We worked on actually storing parent pointers on objects during last years Zope 4 sprint at Plone Conf. But today I doubt using parent pointers actually works. Or at least you have to be really careful with Acquisition wrappers and cannot use API's like OFS.CopySupport or ZEXP export. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers
On Tue, Mar 27, 2012 at 3:50 PM, Patrick Gerken do3cc...@googlemail.com wrote: Hmm, since I didn't understand what magic happens with __parent__ pointers, I tried the following in pdb: unwrapped = aq_base(a) unwrapped.__parent__ = aq_base(a.__parent__) So I stored a not acquisition wrapped object onto the __parent__ attr of another unwrapped object. But then the result, unwrapped.__parent__ was acquisition wrapped again! Yep. That's one thing we changed in Acquisition and ExtensionClass 4.0a1: Prevent wrappers to be created while accessing __parent__ on types derived from Explicit or Implicit base classes. Usually accessing any attribute on a type derived from Acquisition.Explicit or Implicit will force wrapping to take place, unless there's already a wrapper present. Maybe you remember the whole weird story with browser views in Zope 2 and the need for using context = aq_inner(self.context). That was the same problem. Accessing the context attribute of the view (self), created a wrapper equivalent to: context = context.__of__(self), as the view itself wasn't wrapped in anything. For views we got rid of the problem by removing the Acquisition.Implicit base class. For normal content classes in Zope 2, removing the Implicit base class is much harder, as there's more stuff depending on it, and you'd need to ensure to switch every type derived from this, to manually store parent pointers. But the 4.0a1 releases of AQ/EC at least treat __parent__ differently, as it doesn't make much sense to force wrapping for that particular attribute. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers
Hi, I have a very curious problem with relationfields, and I don't know which bugtracker to use for z3c.relationfield. So, hopefully somebody here can give me some pointers. The relations are persistent objects and the from relation is stored directly on them on the from_object. For some reason, the existing relations have from objects without __parent__ or aq_parent pointers. When I update a relation, from_object is updated with an object with __parent__ and aq_parent pointers. After restart, the pointers are gone, the attribute value is None. When I want to delete the relation target object, Plone first starts a savepoint, tries to delete the object, catches any exceptions and does a rollback. It does so to test for certain exception. After the rollback, the objects lost their __parent__ and aq_parent pointers. There was something else that felt odd. the object in from_object always returned a string representation without a path on obj.__str__(), but a string representation with a path when doing obj.__repr__() and when the object had __parent__ pointers. I noticed that, because print statements and pdb tests displayed different things. The whole thing happens in Zope 2.13 with dexterity content types. I have no idea why this could happen. Anybody has any pointers for me? Thanks and best regards, Patrick ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
