My sister was bit by an aq_base once
Is there an inverse operation to: obj = obj.aq_base And if so, what is it? I think I'm relying too much on Zen and not enough on actual understanding. When should I care whether I'm dealing with an object, or an object's Aquisition proxy? I'm having a lot of trouble with my code acting differently after a restart, and I think it's due to either too many or too few aq_bases. Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations
Mike Pelletier wrote:
Is there an inverse operation to:
obj = obj.aq_base
No, unless you happen to have the parent around. Why are you using aq_base in the first place? (snip)
I think I'm relying too much on Zen and not enough on actual understanding.
Zen is understanding. I think you are relying on lore, which looks like, but is not Zen. ;)
When should I care whether I'm dealing with an object, or an object's Aquisition proxy?
Almost never. (The security machinery cares alot, but that's our problem, not yours. ;) A very common reason to use aq_base is to temporarily disable acquisition, for example, to test whether an object as an (unacquired) attribute. There is "now" (meaning in the public CVS and in the next release) a better way to prevent acquisition. Acquisition wrappers now have a new attribute, 'aq_explicit' that returns a new wrapper that is explicit. So, if you want to see if 'obj' has an unacquired attribute, 'spam', you could use: if hasattr(obj.aq_explicit, 'spam'): ... The inverse of aq_explicit is __of__: e=obj.aq_explicit o=e.aq_self.__of__(e.aq_parent) Here 'o' is wrapped the same way 'obj' was. Also note that "now" aq_base is not allowed in DTML.
I'm having a lot of trouble with my code acting differently after a restart, and I think it's due to either too many or too few aq_bases.
It is more likely that you have some sort of persistence problem, such as a pickling problem or a broken persistence rule. (http://www.zope.org/Documentation/Models/ZODB/ZODB_Persistent_Objects_Persis...) One problem we have is that errors that occur during unpickling are not easy to see. :( We ought to fix this, but it's hard, since these errors occur in strange places where error reporting may be unexpected or unwelcomed. I do have an idea for making things better. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Mmm! Lunch tastes better on a patio. On Fri, 30 Apr 1999, Jim Fulton wrote:
Why are you using aq_base in the first place?
I am having trouble comparing self to items in lists or attributes of other objects. In some cases, when I _know_ self and some_obj.some_attr/some_list[0] refer to the same object, they don't evaluate as equal. I haven't figured out the pattern, but whether or not the POS has been restarted seems to be significant in SOME instances. A couple of examples of what I'm trying to do: def UserEntries(self): return filter(lambda a, self=self: self==a.user, self.HGEntries()) def UserTasks(self): return filter(lambda a, self=self: self in a.users, self.HGTasks()) HGEntries and HGTasks are both acquired. They return a list each. It seems to work more reliably when I use "self=self.aq_base" in the second example function.
Zen is understanding. I think you are relying on lore, which looks like, but is not Zen. ;)
I'd debate the definitive definitions of the metaphorical jargon being applied to the grokking of Zope, but that's probably too off topic. One way or the other, I'm not grokking SOMETHING. Thanks! Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations
Ack! This doesn't return anything: filter(lambda a, self=self: self in a.users, self.HGTasks()) This returns what I am actually looking for: filter(lambda a, self=self.aq_base: self in a.users, self.HGTasks()) Should I be having to use aq_base in a case like this? HGTasks, BTW, is very simple and looks like this: return self.objectValues(Task.meta_type) On a related but stranger note, this works exactly like I expect it to: filter(lambda a, self=self: self==a.user, self.HGEntries()) However it does not return anything that has been added to the database this session. You have to restart for it to start returning a particular new item. What is going on there? Mike. -- --- | Mike Pelletier Work: 519-746-1607 /opeware! | Software Developer Home: 519-725-7710 --- | mike@zopeware.com Fax: 519-746-7566 http://www.zopeware.com | Zopeware is not endorsed by Digital Creations
Mike Pelletier wrote:
Ack! This doesn't return anything:
filter(lambda a, self=self: self in a.users, self.HGTasks())
This returns what I am actually looking for:
filter(lambda a, self=self.aq_base: self in a.users, self.HGTasks())
Should I be having to use aq_base in a case like this?
Ugh. Whimper whimper. No, but you do. This is due to a bug in the Acquisition module. It will be a bit painful to fix too. :( The explanation is too complicated to go into here. I'll put this on the to-do list. In the mean time, you'll have to use the work-around that you figured out above.
HGTasks, BTW, is very simple and looks like this:
return self.objectValues(Task.meta_type)
On a related but stranger note, this works exactly like I expect it to:
filter(lambda a, self=self: self==a.user, self.HGEntries())
However it does not return anything that has been added to the database this session. You have to restart for it to start returning a particular new item. What is going on there?
By guess is that wrapped objects are being added to the objects in memory and that they are unwrapped when loaded from the DB. The symptom is probably due to the problem mentioned above. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
participants (2)
-
Jim Fulton -
Mike Pelletier