z3c.relationfield.schema.RelationChoice field view issue

Everything was working until I upgraded from Plone 5.0.7 to 5.0.8

This is in my Policy.xml file:

<field name="change_notice_number" type="z3c.relationfield.schema.RelationChoice" indexer:searchable="true">
 <description/>
<required>False</required>
<title>Change Notice Number</title>
</field>

This is in my policyview.pt template file:

    <tr tal:condition="context/change_notice_number">
        <td><strong>Change Notice Number</strong></td>
        <td><a tal:attributes="href string:${context/change_notice_number/to_object/absolute_url}"><span tal:content="context/change_notice_number/to_object/Title" /></a></td>
    </tr>

If the relation choice field is a blank field, the template will not render. If the field has something, the page renders fine. I can't help but feel that my tal codes are incorrect.

This is the error message I get when the relation choice field is blank:
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module Products.Five.browser.metaconfigure, line 485, in call
Module Products.Five.browser.pagetemplatefile, line 125, in call
Module Products.Five.browser.pagetemplatefile, line 59, in call
Module zope.pagetemplate.pagetemplate, line 132, in pt_render
Module five.pt.engine, line 98, in call
Module z3c.pt.pagetemplate, line 163, in render
Module chameleon.zpt.template, line 261, in render
Module chameleon.template, line 191, in render
Module chameleon.template, line 171, in render
Module 118e7857658c099a1ce91eb7af11a1b6.py, line 833, in render
Module dd869b4dbc66a0eae2e464e617ee3c1d.py, line 1223, in render_master
Module dd869b4dbc66a0eae2e464e617ee3c1d.py, line 420, in render_content
Module 118e7857658c099a1ce91eb7af11a1b6.py, line 821, in __fill_content_core
Module 118e7857658c099a1ce91eb7af11a1b6.py, line 112, in render_content_core
Module five.pt.expressions, line 154, in call
Module five.pt.expressions, line 126, in traverse
Module zope.traversing.adapters, line 136, in traversePathElement
- traceback_info: (None, 'to_object')
Module zope.traversing.adapters, line 50, in traverse
- traceback_info: (None, 'to_object', ('absolute_url',))
LocationError: (None, 'to_object')

 - Expression: "span tal:condition="context/change_notice_number">
        <span class="indent250"><strong>Change Notice Number:</strong></span>
        <a tal:attributes="href string:${context/change_notice_number/to_object/absolute_url}"><span tal:content="context/change_notice_number/to_object/Title" /></a>
    </span>

    <span tal:condition="context/division"><br />
        <span class="indent250"><strong>Division/Administrative Offices:</strong></span><span tal:content="context/division" />
    </span>

    <span tal:condition="context/policy_program"><br />
        <span class="indent250"><strong>Policy Program:</strong></span><span tal:content="context/policy_program" />
    </span>

    <span tal:condition="context/policy_section_number"><br />
        <span class="indent250"><strong>Policy Section Number:</strong></span><span tal:content="context/policy_section_number" />
    </span>

    <span tal:condition="context/policy_effective_date"><br />
        <span class="indent250"><strong>Policy Effective Date:</strong></span><span tal:content="context/policy_effective_date" />
    </span>

    <span tal:condition="context/policy_file"><br />
        <span class="indent250"><strong>Policy File:</strong></span>
        <span><a tal:attributes="href string:${context/absolute_url}/@@download/policy_file/${context/policy_file/filename}"><span tal:content="context/policy_file/filename" /></a></span>
    </span> 

    <hr /"
 - Filename:   ... enttype/economicbenefits/browser/templates/policyview.pt
 - Location:   (line 15: col 8)
 - Source:     ... span tal:condition="context/change_notice_number">
                   ^
 - Arguments:  repeat: {...} (0)
               template: <ViewPageTemplateFile - at 0x7f8699e97b10>
               views: <ViewMapper - at 0x7f8699d6db90>
               modules: <instance - at 0x7f86ad862908>
               args: <tuple - at 0x7f86b52cf050>
               here: <ImplicitAcquisitionWrapper test at 0x7f869be9e280>
               user: <ImplicitAcquisitionWrapper - at 0x7f869bead460>
               nothing: <NoneType - at 0x8fe4d0>
               container: <ImplicitAcquisitionWrapper test at 0x7f869be9e280>
               request: <instance - at 0x7f869acd97e8>
               wrapped_repeat: <SafeMapping - at 0x7f8699791fc8>
               traverse_subpath: <list - at 0x7f869acd9e18>
               default: <object - at 0x7f86b51ec590>
               loop: {...} (0)
               context: <ImplicitAcquisitionWrapper test at 0x7f869be9e280>
               view: <SimpleViewClass from /var/plone/sharedservices/zeocluster/src/ncdhhscontenttype.economicbenefits/src/ncdhhscontenttype/economicbenefits/browser/templates/policyview.pt policyview at 0x7f8699e97a90>
               translate: <function translate at 0x7f8699e811b8>
               root: <ImplicitAcquisitionWrapper Zope at 0x7f869be8aa00>
               options: {...} (0)
               target_language: <NoneType - at 0x8fe4d0>

Any help would be most appreciated. Thank you.

Alas my very limited TAL skills don't allow me to find the problem in a magical flash.
Here is what I know though:
if you set in the environment before starting Plone
export CHAMELEON_DEBUG=true
export CHAMELEON_CACHE=/mydirectory
(adapt the path to your system/computer) the Plone template engine will save the mysterious files with strange names in this directory. They are actually python files generated from your templates. Taking a look at these 2 files at the lines referenced in the trace may be instructive who knows. If Python code (specially code generated by a program) is not your cup of tea you could post the 15 lines before each of the lines number quoted in the trace (833 / 1223 / 420 / 821 / 112). I'd even say that the more interesting could be the last (line 112). That's the part I would examine first.

the problem is by default relations are stored as paths instead of UUID; that means your relations are broken when you move related content from one place to another and then you have to fix those problems accessing directly the ZODB.

we have been bitten by that issue multiple times; I think that's a bug on:

fixing that can be a little bit complex and could require a PLIP.

Thanks hvelarde. This makes sense.