#38 — Problem caused by removal of updateBackReferences

by Sam Allgood — last modified Feb 19, 2009 06:28 PM
State Confirmed
Version:
—
Area Functionality
Issue type Bug
Severity Medium
Submitted by Sam Allgood
Submitted on Feb 17, 2009
Responsible Damien Baty
Target release: 1.7.1
Return to tracker
In reference to issue number 33, removal of '_updateBackReferences()' apparently does have undesireable side-effects. We are receiving numerous error reports in our error log as follows:

Jan 14 00:23:07 extzope1 Archetypes 2 references for non multivalued field internal_link of <ComboLink at report_criminals>

ComboLink is a local extension of ATLink that adds an internal_link field using ATReferenceBrowserWidget.

Testing has revealed that the cause of the reported problem is Creating a new version (using StagingAddOn 1.7.1) and publishing the new version. Once I delete the old archived version, the problem disappears.

I readded the _updateBackReferences call and definition, retested, and the problem does not occur.

Any chance of getting it added back in?
Added by Damien Baty on Feb 19, 2009 12:06 AM
Issue state: Unconfirmed → Confirmed
Responsible manager: (UNASSIGNED) → dbaty
Target release: None → 1.7.1
First, is this an error or only a warning? I suppose that it is a warning. If this is an error message, would it be possible to post the complete error traceback?

If I understand correctly, your ComboLink content type has a "internal_link" field that contains an UID (changed via an ATRefBrowserWidget). But I am not sure I understand when the error occurs: when you create and publish a new version of the combo link, or when you create and publish a new version of the linked item. I suppose that it is the latter, right? Given the error message and the way you make it disappear, I would say that both the old (archived) and the new (published) version of the linked item have the same UID. Would it be possible to check? (Just call "UID()" on each object. I do not think that the method is published, so you will probably have to do that from a script. Ask me if you need assistance.)

... But this should not happen, since the code clearly swaps UID when the new version is promoted and replaces the published version. So that may man that, in the first place, both the currently published version and the new version (not yet published) have the same UID. Could you check that, please? That is, create an item, then click on "create a new version", and check the UID of these two items. They should not be equal. I mean, theoretically, they should not, but this would explain the bug you describe...
Added by Damien Baty on Feb 19, 2009 12:30 AM
Err... forget what I said. I do not think that they have the same UID. But the catalog might very well think that they do, since we do not reindex them after having swapped the UIDs.

Could you please try the following:

- revert your changes so that you have the code of the 1.7.1 release and can reproduce the bug;

- add the following lines in "StagingAddOn/content/staging_tool.py", at line 324 (just after "obj._setUID(old_uid)") :

    old.reindex_object(['UID'])
    obj.reindex_object(['UID'])

- restart Zope and try to reproduce the bug.

If you confirm that it fixes your bug, you will have to reindex your old objects (actually, only the "UID" index) to be on the safe side. I will try to make a release but this will not happen before next week, I guess ("Kölle Alaaf!").

(The code of "Archetypes.Referenceable.Referenceable._setUID()" says that the item will be reindexed in the reference catalog, but it does not talk about the "portal_catalog", which seems to be used by default by ATReferenceBrowserWidget. Hence the proposed solution, which would trigger the reindexation of the content.)
Added by Sam Allgood on Feb 19, 2009 12:15 PM
The error message was reported earlier in issue # 33. Will try to get the tests/changes you recommend done today.
Added by Sam Allgood on Feb 19, 2009 06:08 PM
Original link:
UID of link object: d184af79b3696b35c9437789e943b86f
UID of target object: 6eef1b4916709f6525f481b5a91184a1

New Version of Link (while still in draft):
UID of link object: 233f32528e5a72817bf1be78042c9798
UID of target object: 6eef1b4916709f6525f481b5a91184a1

Archived version after publishing:
UID of link object: 233f32528e5a72817bf1be78042c9798
UID of target object: None Found

New version after publishing:
UID of link object: d184af79b3696b35c9437789e943b86f
UID of target object: 6eef1b4916709f6525f481b5a91184a1

These messages appear in the events.log when I publish the new link:
2009-02-19T12:50:51 ERROR Zope.ZCatalog uncatalogObject unsuccessfully attempted to uncatalog an object with a uid of information-technology/custom/test_link/at_references/3e5e5719cacb20d5008a7f5b7cec863d.
------
2009-02-19T12:50:51 ERROR Zope.ZCatalog uncatalogObject unsuccessfully attempted to uncatalog an object with a uid of information-technology/custom/test_link-new-version/at_references/3e6108f404dcf924ac7d939c4aa7fc50.
------
2009-02-19T12:50:52 INFO Archetypes [00m[01;32mProducts/Archetypes/Field.py[1598]:get
[00m2 references for non multivalued field internal_link of <ComboLink at test_link-old-version-replaced-19022009-125051>

------
2009-02-19T12:50:52 INFO Archetypes 2 references for non multivalued field internal_link of <ComboLink at test_link-old-version-replaced-19022009-125051>

------
2009-02-19T12:50:52 INFO Archetypes 2 references for non multivalued field internal_link of <ComboLink at test_link>


I will now make the changes you recommended and test again.
Added by Sam Allgood on Feb 19, 2009 06:28 PM
After making changes and restarting, I created a new link and new version, published the new version and got the exact same results, to include the messages in events.log.

Actually did it twice because the first time errored ... reindex_object should have been reindexObject.

No responses can be added.