Objects in transaction-Object do not support absolute_url() (was: Re: [Zope] Catch Object Changes)
Hallo Dieter, am Montag, 1. Dezember 2003 um 18:52 schrieben Sie: DM> Holger Schmidt wrote at 2003-11-30 15:17 +0100:
... DM> Looks like you want a specialized transaction or ZODB connection.
DM> Whenever an object is changed, it registers with the transaction.
DM> When the transaction is about to commit, it informs DM> the object's ZODB connection that the object was modified.
DM> Zope uses a two level commit protocol, thus one affected DM> connection may vote against the commit.
DM> This means, the hook you are looking for is somewhere in DM> transaction or two level commit handling.
do you mean a monkey-patch like this? or is this bad for any reasons ...?
... patching "Connection.commit/commit_sub" ...
I patched the commit and the commit_sub because I think these methods are called after 2PC has succeded, has it?
DM> The 2-level commit protocol looks like (at the connection interface): DM> tpc_begin --> commit (for each object) --> tpc_vote DM> --> (tpc_finish | tpc_abort) DM> Thus, when you patch "commit", there is still a chance that DM> lateron the complete transaction is aborted. DM> "tpc_finish" is the "final commit". New Problem: now i monkey-patch tpc_finish, but what I get is just the transaction-object. In the transaction-Object I can find the affected Objects of the TA (in the "_objects"-List I think) ... But I cannot get the absolute URL of the affected Objects (cannot use obj.absolute_url()), I think this is because the objects in the transaction-object are not acquisition wrapped, are they? Is there a chance to get the path to the object? -- Thanks, Holger
Hello, am Mittwoch, 3. Dezember 2003 um 19:28 schrieben Sie: HS> Hallo Dieter, HS> am Montag, 1. Dezember 2003 um 18:52 schrieben Sie: DM>> Holger Schmidt wrote at 2003-11-30 15:17 +0100:
... DM> Looks like you want a specialized transaction or ZODB connection.
DM> Whenever an object is changed, it registers with the transaction.
DM> When the transaction is about to commit, it informs DM> the object's ZODB connection that the object was modified.
DM> Zope uses a two level commit protocol, thus one affected DM> connection may vote against the commit.
DM> This means, the hook you are looking for is somewhere in DM> transaction or two level commit handling.
do you mean a monkey-patch like this? or is this bad for any reasons ...?
... patching "Connection.commit/commit_sub" ...
I patched the commit and the commit_sub because I think these methods are called after 2PC has succeded, has it?
DM>> The 2-level commit protocol looks like (at the connection interface): DM>> tpc_begin --> commit (for each object) --> tpc_vote DM>> --> (tpc_finish | tpc_abort) DM>> Thus, when you patch "commit", there is still a chance that DM>> lateron the complete transaction is aborted. DM>> "tpc_finish" is the "final commit". HS> New Problem: HS> now i monkey-patch tpc_finish, but what I get is just the HS> transaction-object. HS> In the transaction-Object I can find the affected Objects of the TA HS> (in the "_objects"-List I think) ... HS> But I cannot get the absolute URL of the affected Objects (cannot use HS> obj.absolute_url()), I think this is because the objects in the HS> transaction-object are not acquisition wrapped, are they? HS> Is there a chance to get the path to the object? btw obj.getPhysicalPath() just returns the id of the object not the path :( -- Holger
Holger Schmidt wrote at 2003-12-3 19:28 +0100:
... New Problem:
now i monkey-patch tpc_finish, but what I get is just the transaction-object. In the transaction-Object I can find the affected Objects of the TA (in the "_objects"-List I think) ... But I cannot get the absolute URL of the affected Objects (cannot use obj.absolute_url()), I think this is because the objects in the transaction-object are not acquisition wrapped, are they?
You are right: they are not acquisition wrapped.
Is there a chance to get the path to the object?
In Zope3, but (I fear) not in Zope2. Zope3 abandons acquistion (or more generally: "context wrapper"s) and puts an explicit parent attribute in objects. If you have control over the objects, you can emulate Zope3 behaviour in some sense. E.g. you can code the path in an attribute of the object (be carefull with copy/move/rename). -- Dieter
On Wed, 3 Dec 2003 21:20:50 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Holger Schmidt wrote at 2003-12-3 19:28 +0100: [snip]
Is there a chance to get the path to the object?
In Zope3, but (I fear) not in Zope2.
Zope3 abandons acquistion (or more generally: "context wrapper"s) and puts an explicit parent attribute in objects.
If you have control over the objects, you can emulate Zope3 behaviour in some sense. E.g. you can code the path in an attribute of the object (be carefull with copy/move/rename).
You could store the path as an _v_ attribute perhaps when the object is registered. That should alleviate problems with copy/move since _v_ attrs aren't persisted. -Casey
Casey Duncan wrote at 2003-12-4 14:08 -0500:
On Wed, 3 Dec 2003 21:20:50 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Holger Schmidt wrote at 2003-12-3 19:28 +0100: [snip]
Is there a chance to get the path to the object?
In Zope3, but (I fear) not in Zope2.
Zope3 abandons acquistion (or more generally: "context wrapper"s) and puts an explicit parent attribute in objects.
If you have control over the objects, you can emulate Zope3 behaviour in some sense. E.g. you can code the path in an attribute of the object (be carefull with copy/move/rename).
You could store the path as an _v_ attribute perhaps when the object is registered. That should alleviate problems with copy/move since _v_ attrs aren't persisted.
I do not think, it will work. As a side effect how acquisition works, the registering objects are unwrapped (if they are persistent objects and they register automatically because they have been modified): Assigning to an object's attribute (or accessing an object's attribute) effectively works on "aq_base". This implies (among others) that the "self" of "__getattr__" and "__setattr__" are unwrapped. It also implies that (automatically) registered objects are unwrapped. -- Dieter
On Thu, 4 Dec 2003 22:43:27 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Casey Duncan wrote at 2003-12-4 14:08 -0500: [snip]
I do not think, it will work.
As a side effect how acquisition works, the registering objects are unwrapped (if they are persistent objects and they register automatically because they have been modified):
Assigning to an object's attribute (or accessing an object's attribute) effectively works on "aq_base". This implies (among others) that the "self" of "__getattr__" and "__setattr__" are unwrapped. It also implies that (automatically) registered objects are unwrapped.
Ok, but I wasn't talking about storing wrappers or relying on the object being wrapped at all. Just storing the physical path (string or tuple) at some opportune point (probably at a higher level in the application) when the object was modified. Then given this path and the application object (which you could get to from _p_jar), you could recreate the wrapper if you needed it. -Casey
Hallo Dieter, am Mittwoch, 3. Dezember 2003 um 21:20 schrieben Sie: DM> Holger Schmidt wrote at 2003-12-3 19:28 +0100:
... New Problem:
now i monkey-patch tpc_finish, but what I get is just the transaction-object. In the transaction-Object I can find the affected Objects of the TA (in the "_objects"-List I think) ... But I cannot get the absolute URL of the affected Objects (cannot use obj.absolute_url()), I think this is because the objects in the transaction-object are not acquisition wrapped, are they?
DM> You are right: they are not acquisition wrapped.
Is there a chance to get the path to the object?
DM> In Zope3, but (I fear) not in Zope2. DM> Zope3 abandons acquistion (or more generally: "context wrapper"s) DM> and puts an explicit parent attribute in objects. DM> If you have control over the objects, you can emulate DM> Zope3 behaviour in some sense. E.g. you can code DM> the path in an attribute of the object (be carefull DM> with copy/move/rename). Another try: I have this list of objects which I tried to compare to the changed objects (in the transaction) via the absolute_url()-method ... Is there a better solution to compare my list of objects with the object I get which is affected by the transaction? Is there any chance to compare the objects in my list with the objects i get from the transaction so that i could realize that a special object of my list has changed ...? Any Ideas ...? -- Thanks, Holger
participants (3)
-
Casey Duncan -
Dieter Maurer -
Holger Schmidt