Possible bug in Integrity Checker

[jgreen]

I'm seeing what I believe to be a bug in the node integrity checker.

It appears that Alfresco is not constraining it's integrity checks to the appropriate node.

Essentially, within a folder I have a content type that has 3 associations to other content types, with 0 to many associations.

When I create the first content node, everything is fine and associations can be edited appropriately.

However, if I create a nother content node of the same type within the folder, the associations cannot be the same and Alfresco is throwing:

14:00:34,103 ERROR [node.integrity.IntegrityChecker] Found 1 integrity violations:
The association source multiplicity has been violated:
   Association: Association[ class=ClassDef[name={http://www.goecon.net/model/process/1.0}procedure], name={http://www.goecon.net/model/process/1.0}Inputs, target class={http://www.goecon.net/model/process/1.0}deliverableDefinition, source role=null, target role=n
ull]
   Required source Multiplicity: 1..1
   Actual source Multiplicity: 0
14:00:34,304 ERROR [util.transaction.SpringAwareUserTransaction] Transaction didn't commit
org.alfresco.repo.node.integrity.IntegrityException: Integrity failure
        at org.alfresco.repo.node.integrity.IntegrityChecker.checkIntegrity(IntegrityChecker.java:611)….
‍‍‍‍‍‍‍‍‍‍‍

This occurs whenever an attempt to create an association to a node used in  another association exists.

Example probably explains this best

Here's the relevant chunk of the content definition

<type name="prc:deliverableDefinition">
   <title>Deliverable Definition</title>
   <parent>cm:content</parent>
   <mandatory-aspects>
      <aspect>cm:versionable</aspect>
   </mandatory-aspects>
</type>

<type name="prc:procedure">
   <title>Procedure</title>
   <description>Procedure</description>
   <parent>cm:content</parent>

   <associations>
      <association name="prc:Owner">
         <target>
            <class>cm:person</class>
            <mandatory>false</mandatory>
            <many>false</many>
         </target>
      </association>

      <association name="prc:Inputs">
         <target>
            <class>prc:deliverableDefinition</class>
            <mandatory>false</mandatory>
            <many>true</many>
         </target>
      </association>

      <association name="prc:Outputs">
         <target>
            <class>prc:deliverableDefinition</class>
            <mandatory>false</mandatory>
            <many>true</many>
         </target>
      </association>

      <association name="prc:Tools">
         <target>
            <class>prc:tool</class>
            <mandatory>false</mandatory>
            <many>true</many>
         </target>
      </association>

   </associations>

   <mandatory-aspects>
      <aspect>cm:versionable</aspect>
   </mandatory-aspects>
</type>

<type name="prc:process">
   <title>Process</title>
   <parent>cm:folder</parent>
   <properties>

      <property name="prc:status">
         <title>Process Status</title>
         <type>d:text</type>
      </property>

   </properties>
</type>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

When I create a Process with 2 Procedures in it, the associations to the deliverables are mutially exclusive. 

If I use Deliverable1 as input to Process 1, I cannot, then use it as input to process 2, and once used, the deliverables cannot be deleted from the associations either.

I cleaned out the DB and content stores and restarted from scratch, so I know it's now stuff left over from previous testing.

Also rebuilt the repository from todays SVN, same issue.

What really concerns me is that the error message seems to say that I have a 1..1 association that's being violated, but there are none defined in my content model.  Once this happens, it's basically impossible to edit the association.

I tried replacing one deliverable with another and get 2 integrity violations:

   Association: Association[ class=ClassDef[name={http://www.goecon.net/model/process/1.0}procedure], name={http://www.goecon.net/model/process/1.0}Inputs, target class={http://www.goecon.net/model/process/1.0}deliverableDefinition, source role=null, target role=null]
   Required source Multiplicity: 1..1
   Actual source Multiplicity: 2

   Association: Association[ class=ClassDef[name={http://www.goecon.net/model/process/1.0}procedure], name={http://www.goecon.net/model/process/1.0}Inputs, target class={http://www.goecon.net/model/process/1.0}deliverableDefinition, source role=null, target role=null]
   Required source Multiplicity: 1..1
   Actual source Multiplicity: 0
‍‍‍‍‍‍‍‍‍

I'm digging into this a little deeper, but has anyone experienced anything like this before ?

[derek]

Hi,

You have an implied source multiplicity, which is what it is complaining about.  When you omit the source multiplicity definition, it assumes a mandatory source on that association.  This doesn't mean that an association needs to have a source node (that is implied), it means that the target node must be attached to a source node via the association in question.

So, I read the model as:
You can have a prcrocedure standalone.
A prc:deliverableDefinition must be the target of both a prc:Inputs and a prcutputs association.

Anyway, it doesn't mean there isn't a bug.  But set the association source attributes explicitly and if you still have problems, post your code here and I'll put it into a test to validate.

Regards

[jgreen]

Thanks, I was just opening this up to say I figured it out, once I opened it up with the debugger and realized it checked both endpoints it was pretty odvious what the problem was.

This is my first foray into Doc Management, most of my data modeling experience comes from the Relational world, and I was thinking in terms of foreign keys specifications.

What would happen in this case (or is this even possible)

An association could be multiply-defined between 2 content types in both the source and target specifications, in a way that would generate a conflict as in:

<type name="prc:deliverableDefinition">
   <associations>
      <association name="prc:Inputs">
         <source>
            <many>false</many>
         </source>
         <target>
            <class>prc:procedure</class>
            <mandatory>false</mandatory>
            <many>true</many>
         </target>
      </association>
   </associations>
</type>

<type name="prc:procedure">
   <associations>
      <association name="prc:Inputs">
         <source>
            <many>true</many>
         </source>
         <target>
            <class>prc:deliverableDefinition</class>
            <mandatory>false</mandatory>
            <many>true</many>
         </target>
      </association>
   </associations>
</type>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[derek]

Hi,

I'm glad to hear that it's working for you.  My initial thoughts on the model snippet are that it should be fine.  If I recall correctly (I'm a bit lazy to look at the code right now), the dictionary stores associations within the context of their defining types.  There shouldn't be a conflict between the two association names.

Regards