Hello,
In theory this is a pretty generic problem (so not just affecting
DistanceConstraintItems). So everything (that is not a singleton) in
version 1 is a list, so elements do not have to be unique, whereas in
version 2 most things are sets, so elements have to be unique.
My guess, though, is that DistanceConstraintItems are the most likely to
suffer from this. But I'm a bit worried about trying to put a blanket
delete in the upgrade script although I guess it could be done. For now
I've written a script, which I've attached, which will delete redundant
DistanceConstraintItems but only after asking you if it's ok. (Not that
you would necessarily have a feel whether or not it is ok!)
You can run the script outside of (version 1) Analysis via:
python deleteRedundantConstraintItems.py PROJECT_FILE
(assuming that the ccpnmr/ccpnmr1.0/python is on your PYTHONPATH) or you
can run it inside (version 1) Analysis via:
>>> from deleteRedundantConstraintItems import deleteRedundantConstraintItems
>>> deleteRedundantConstraintItems(top.project)
In both cases it asks whether you want to save the project. For the
outside Analysis version you would answer yes unless you suddenly were
worried that maybe you shouldn't have deleted all those items. Inside
Analysis it's neither here nor there but I'd recommend instead using the
Analysis Save menu option because that first does a backup of the project
whereas this script does not.
(I tested this on your project from both inside and outside Analysis and
it seemingly worked.)
Wayne
On Wed, 29 Jul 2009, Gary Thompson wrote:
> Wayne Boucher wrote:
>> Hello,
>>
>> It turns out that the problem is an inconsistency that version 1 allowed
>> (in fact so much so that even checkValid() doesn't catch it). So that
>> constraint (serial 1026) had two items that were both pointing to the same
>> two resonances, but in the opposite order (version 2 code uses sets not
>> lists so that cannot happen now). With Rasmus' help I removed the
>> offending bits in the xml file and then the upgrade worked, so fortunately
>> that was the only example of this problem. I'll send you the link in a
>> subsequent email.
>>
>> Wayne
> Hi Wayne & Rasmus
>
> many thanks
>
> If we have to submit the same thing again or something similar will this die
> again or will the update script be patched as well? ;-)
>
> regards
> gary
>>
>> On Wed, 29 Jul 2009, Gary Thompson wrote:
>>
>>> Hi
>>>
>>> we tried to convert a 1.0 project to a 2.0 project using the online server
>>> and got the following error:
>>>
>>> Job failed: ApiError: Cannot add child - key already in use:
>>> ccp.nmr.NmrConstraint.DistanceConstraintItem:<ccp.nmr.NmrConstraint.DistanceConstraint
>>> [1, 1, 1026]>:frozenset([<ccp.nmr.NmrConstraint.FixedResonance [1, 2]>,
>>> <ccp.nmr.NmrConstraint.FixedResonance [1, 4]>])
>>> File "/data/ccpn/www/cgi-bin/upgrade/upgrade", line 575, in
>>> convertMajorProject
>>> doMajorConvert(dataStem)
>>> File "/data/ccpn/www/cgi-bin/upgrade/upgrade", line 549, in doMajorConvert
>>> p = Converters.doMajorUpgradeToCurrent(oldPath, oldTag, newDir=newDir)
>>> File
>>> "/data/ccpn/upgrade/cvsroot_branch_2_0_3/ccpn/python/memops/format/compatibility/Converters.py",
>>> line 76, in doMajorUpgradeToCurrent
>>> globalMapping=globalMapping, oldTags=oldTags)
>>> File
>>> "/data/ccpn/upgrade/cvsroot_branch_2_0_3/ccpn/python/memops/format/compatibility/part1/Converters1.py",
>>> line 95, in majorUpgradeToCurrent
>>> return upgrader.majorUpgrade(doSave=doSave)
>>> File
>>> "/data/ccpn/upgrade/cvsroot_branch_2_0_3/ccpn/python/memops/format/compatibility/part1/Converters1.py",
>>> line 204, in majorUpgrade
>>> self.transferData()
>>> File
>>> "/data/ccpn/upgrade/cvsroot_branch_2_0_3/ccpn/python/memops/format/compatibility/part1/Converters1.py",
>>> line 618, in transferData
>>> oldVersionStr=self.oldVersionStr)
>>> File
>>> "/data/ccpn/upgrade/cvsroot_branch_2_0_3/ccpn/python/memops/general/Util.py",
>>> line 1008, in transferData
>>> linkTopToParent=True)
>>> File
>>> "/data/ccpn/upgrade/cvsroot_branch_2_0_3/ccpn/python/memops/xml/Implementation.py",
>>> line 4750, in linkChildData
>>> + ": %s:%s:%s" % (obj.getQualifiedName(), obj.getParent(), key)
>>>
>>>
>>> however, the response from the server gives no information as to what to
>>> do next... It seems that the original project isn't valid ....
>>>
>>>
>>> regards
>>> gary
>>>
>>
>> .
>>
>
|