Problem with Unique Constraint

, ,
1

Hi

I created a new schema and defined the unique constraint as specified in the documentation, adding the SXS in the trigger and creating the appinfo.

At first, the constraint does not allow me to add new instances to Tamino. The only way I can get the constraint to work correctly, is to remove the trigger, add some (duplicate) instances without the constraint, then add the trigger to the schema and redefine it to Tamino. After this I am correctly prohibited from adding duplicates and can add unique instances.

So it seems that only once the contraint has ‘kicked in’ by doing some validations on current instances does it work properly.

This seems bizarre. What am I doing wrong? I am using Tamino 4.1.4.1 and have loaded the hotfix H4_1_4_208.

The schema is 

 <?xml version = "1.0" encoding = "UTF-8"?>
<xs:schema elementFormDefault = "qualified" xmlns:tsd = "http://namespaces.softwareag.com/tamino/TaminoSchemaDefinition" xmlns:xs = "http://www.w3.org/2001/XMLSchema">
  <xs:annotation>
    <xs:appinfo>
      <tsd:schemaInfo name = "AccountTypeCode">
        <tsd:collection name = "sdl"></tsd:collection>
        <tsd:doctype name = "AccountTypeCode">
          <tsd:logical>
            <tsd:content>closed</tsd:content>
          </tsd:logical>
        </tsd:doctype>
      </tsd:schemaInfo>
    </xs:appinfo>
  </xs:annotation>
  <xs:annotation>
    <xs:appinfo>
      <tse:schemaExtension xmlns:tse = "http://namespaces.softwareag.com/tamino/TaminoSchemaExtension">
        <tse:doctype name = "AccountTypeCode">
          <tse:unique name = "AccountType-key">
            <tse:field xpath = "."></tse:field>
          </tse:unique>
        </tse:doctype>
      </tse:schemaExtension>
    </xs:appinfo>
  </xs:annotation>
  <xs:element name = "AccountTypeCode" type = "xs:string">
    <xs:annotation>
      <xs:appinfo>
        <tsd:elementInfo>
          <tsd:logical>
            <tsd:trigger>
              <tsd:onInsert type = "action">UniqueConstraintSXS.onInsert</tsd:onInsert>
              <tsd:onUpdate type = "action">UniqueConstraintSXS.onUpdate</tsd:onUpdate>
            </tsd:trigger>
          </tsd:logical>
        </tsd:elementInfo>
      </xs:appinfo>
      <xs:documentation>Type of bank account (i.e. current, credit etc.)</xs:documentation>
    </xs:annotation>
  </xs:element>
</xs:schema>




Regards
Elsabe Jacobs

2

Well I suppose you can ignore this entry as it works 100% now.

I am not sure what has changed. My schema now looks exactly like my schema then so I assume it is something in Tamino?

Has anyone else experienced this behaviour?

Thanks
Elsabe

3

Hello Elsabe,

could you please post one of the documents that you experienced the problem with?

I defined your schema into Tamino 4.1.4.3, then created a simple document conforming to it:

   <?xml version="1.0" encoding="UTF-8"?>
   <AccountTypeCode>A</AccountTypeCode></pre><BR>When I tried to insert this document the first time, it loaded correctly.  When I tried to load it again, I received an error message from the Server Extension.<BR><BR>If Server Extension logging is activated, some interesting information will be written to the log.  In particular the X-Query expressions used to check unique constraints.<BR>For the document shown above the following X-Query was executed:<BR><pre class="ip-ubbcode-code-pre">   boolean(/AccountTypeCode[@ino:id!="2"][(.="A")])


To explain this a little bit: the first time I inserted the document it was assigned ino:id=1. The second insert assigned ino:id=2, and the X-Query shown is checking that there is no “AccountTypeCode” document except this one (@ino:id!=“2”) with the value “A”.

If you experience similar problems later (or if you would like to investigate the problem that mysteriously solved itself), perhaps you could activate logging and try executing some of the X-Query expressions “by hand”. Don’t use the [@ino:id=…] filter, just check if any documents match the second filter condition. (Perhaps I should elaborate on this last point: it is conceivable that the generated X-Query expression is somehow incorrect. The easiest way to check the generated expressions is to try and execute them.)

Greetings,
Trevor.

4

Hi Trevor

Thanks for the information about the log. I’m sure it will come in handy at some stage.

We have noticed that the Unique Constraint is ‘case sensitve’. Is there a way of changing this? For instance that it detects ‘saving’ and ‘Saving’ and ‘SAVING’ as being the same?

Regards
Elsabe