Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-11182

Clear out all locking keys on Maintenance copy, not just the main object

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Epic Link:
    • Rice Module:
      KRAD
    • Application Requirement:
      KFS, KC
    • Sprint:
      Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4, Middleware 2.5.2 Sprint 5
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      5

      Description

      Reported via James Smith:

      About a month ago, I discovered an issue in TEM where a business object with children was being maintained on a maint doc. The business object itself and more importantly, the collection of children objects, all used synthetic keys based on a sequence as their PK’s, and on copy, I found we had to clear the PK’s manually in the processAfterCopy on the maintainable so that the PK’s were reassigned with the document saved them again; if we didn’t do the key clearing, then the children business objects were “stolen” by the object created by the copy and removed from the original. I talked to Doug Pace to see what KC did about this, and he saw two examples of this: one where they cleared the keys and one where they had forgotten (causing the “stealing” issue). Again: I’m not sure what help KRAD could provide to avoid this situation but it’s so easy to forget and cause problems that if there was a way to fix it, I think it would be very helpful for all of the client applications.

      At this time, it looks like we are clearing the basic primary keys but do not have the code to clear all keys associated with the maintenance document, like those on collections or those on child objects. We should be doing this if preserveLockingKeysOnCopy is not set. Verify whether this is still a problem in KRAD and fix it if it is.

        Attachments

          Issue Links

            Activity

            kbtaylor Kristina Taylor (Inactive) created issue -
            jcoltrin Jessica Coltrin (Inactive) made changes -
            Field Original Value New Value
            Fix Version/s Backlog [ 15811 ]
            Fix Version/s 2.4 [ 16913 ]
            kbtaylor Kristina Taylor (Inactive) made changes -
            Rank Ranked lower
            mztaylor Martin Taylor (Inactive) made changes -
            Reporter Kristina Taylor [ kbtaylor ] James Smith [ jksmith ]
            Hide
            mztaylor Martin Taylor (Inactive) added a comment -

            Can you provide a link to the CGB Code Changes related to this ticket?

            Show
            mztaylor Martin Taylor (Inactive) added a comment - Can you provide a link to the CGB Code Changes related to this ticket?
            Hide
            jksmith James Smith added a comment -

            An example can be found here: https://github.com/kuali/kfs/blob/master/work/src/org/kuali/kfs/module/tem/document/maintenance/AgencyStagingDataMaintainable.java in the processAfterCopy method. Towards the bottom of the method, the id and parent agency staging data id of the TripAccountingInformation is set to null - those are the synthetic keys which OJB will only repopulate if they were set to null. Does that help, Martin?

            Show
            jksmith James Smith added a comment - An example can be found here: https://github.com/kuali/kfs/blob/master/work/src/org/kuali/kfs/module/tem/document/maintenance/AgencyStagingDataMaintainable.java in the processAfterCopy method. Towards the bottom of the method, the id and parent agency staging data id of the TripAccountingInformation is set to null - those are the synthetic keys which OJB will only repopulate if they were set to null. Does that help, Martin?
            Hide
            mztaylor Martin Taylor (Inactive) added a comment -
                /**
                 * @see org.kuali.rice.kns.maintenance.KualiMaintainableImpl#processAfterCopy(org.kuali.rice.kns.document.MaintenanceDocument, java.util.Map)
                 */
                @Override
                public void processAfterCopy(MaintenanceDocument document, Map<String,String[]> parameters) {
                    super.processAfterCopy(document, parameters);
                    AgencyStagingData agencyData = (AgencyStagingData) getBusinessObject();
                    agencyData.setManualCreated(true);
                    agencyData.setCreationTimestamp(getDateTimeService().getCurrentTimestamp());
            
                    AgencyStagingDataMaintainable oldMaintainable = (AgencyStagingDataMaintainable)document.getOldMaintainableObject();
                    //this is not new, so it must be for copy - we will set the Copied From Id
                    agencyData.setCopiedFromId(((AgencyStagingData)oldMaintainable.getBusinessObject()).getId());
            
                    //set TripAccountingInformation primary key and foreign key to null so the maintainance document can handle setting the appropriate key values
                    if (!agencyData.getTripAccountingInformation().isEmpty()) {
                        for(TripAccountingInformation account : agencyData.getTripAccountingInformation()) {
                            account.setId(null);
                            account.setAgencyStagingDataId(null);
                        }
                    }
                }
            
            Show
            mztaylor Martin Taylor (Inactive) added a comment - /** * @see org.kuali.rice.kns.maintenance.KualiMaintainableImpl#processAfterCopy(org.kuali.rice.kns.document.MaintenanceDocument, java.util.Map) */ @Override public void processAfterCopy(MaintenanceDocument document, Map< String , String []> parameters) { super .processAfterCopy(document, parameters); AgencyStagingData agencyData = (AgencyStagingData) getBusinessObject(); agencyData.setManualCreated( true ); agencyData.setCreationTimestamp(getDateTimeService().getCurrentTimestamp()); AgencyStagingDataMaintainable oldMaintainable = (AgencyStagingDataMaintainable)document.getOldMaintainableObject(); // this is not new , so it must be for copy - we will set the Copied From Id agencyData.setCopiedFromId(((AgencyStagingData)oldMaintainable.getBusinessObject()).getId()); //set TripAccountingInformation primary key and foreign key to null so the maintainance document can handle setting the appropriate key values if (!agencyData.getTripAccountingInformation().isEmpty()) { for (TripAccountingInformation account : agencyData.getTripAccountingInformation()) { account.setId( null ); account.setAgencyStagingDataId( null ); } } }
            cniesen Claus Niesen made changes -
            Fix Version/s 2.1.10 [ 17909 ]
            Fix Version/s Backlog [ 15811 ]
            cniesen Claus Niesen made changes -
            Epic Link KULRICE-14056 [ 149918 ]
            cniesen Claus Niesen made changes -
            Sprint Middleware 2.5.2 Sprint 3 [ 433 ]
            cniesen Claus Niesen made changes -
            Rank Ranked higher
            cniesen Claus Niesen made changes -
            Description Reported via James Smith:

            {quote}
            About a month ago, I discovered an issue in TEM where a business object with children was being maintained on a maint doc. The business object itself and more importantly, the collection of children objects, all used synthetic keys based on a sequence as their PK’s, and on copy, I found we had to clear the PK’s manually in the processAfterCopy on the maintainable so that the PK’s were reassigned with the document saved them again; if we didn’t do the key clearing, then the children business objects were “stolen” by the object created by the copy and removed from the original. I talked to Doug Pace to see what KC did about this, and he saw two examples of this: one where they cleared the keys and one where they had forgotten (causing the “stealing” issue). Again: I’m not sure what help KRAD could provide to avoid this situation but it’s so easy to forget and cause problems that if there was a way to fix it, I think it would be very helpful for all of the client applications.
            {quote}

            At this time, it looks like we are clearing the basic primary keys but do not have the code to clear all keys associated with the maintenance document, like those on collections or those on child objects. We should be doing this if {{preserveLockingKeysOnCopy}} is not set. Verify whether this is still a problem in KRAD and fix it if it is.
            Reported via James Smith:

            {quote}
            About a month ago, I discovered an issue in TEM where a business object with children was being maintained on a maint doc. The business object itself and more importantly, the collection of children objects, all used synthetic keys based on a sequence as their PK’s, and on copy, I found we had to clear the PK’s manually in the processAfterCopy on the maintainable so that the PK’s were reassigned with the document saved them again; if we didn’t do the key clearing, then the children business objects were “stolen” by the object created by the copy and removed from the original. I talked to Doug Pace to see what KC did about this, and he saw two examples of this: one where they cleared the keys and one where they had forgotten (causing the “stealing” issue). Again: I’m not sure what help KRAD could provide to avoid this situation but it’s so easy to forget and cause problems that if there was a way to fix it, I think it would be very helpful for all of the client applications.
            {quote}

            At this time, it looks like we are clearing the basic primary keys but do not have the code to clear all keys associated with the maintenance document, like those on collections or those on child objects. We should be doing this if {{preserveLockingKeysOnCopy}} is not set. Verify whether this is still a problem in KRAD and fix it if it is. May also need to apply fixes to versions greater than 2.1.
            sonam Sona Sona (Inactive) made changes -
            Assignee Sona Sona [ sonam ]
            sonam Sona Sona (Inactive) made changes -
            Assignee Sona Sona [ sonam ]
            sonam Sona Sona (Inactive) made changes -
            Link This issue discovered KULRICE-14096 [ KULRICE-14096 ]
            cniesen Claus Niesen made changes -
            Story Points 5
            cniesen Claus Niesen made changes -
            Description Reported via James Smith:

            {quote}
            About a month ago, I discovered an issue in TEM where a business object with children was being maintained on a maint doc. The business object itself and more importantly, the collection of children objects, all used synthetic keys based on a sequence as their PK’s, and on copy, I found we had to clear the PK’s manually in the processAfterCopy on the maintainable so that the PK’s were reassigned with the document saved them again; if we didn’t do the key clearing, then the children business objects were “stolen” by the object created by the copy and removed from the original. I talked to Doug Pace to see what KC did about this, and he saw two examples of this: one where they cleared the keys and one where they had forgotten (causing the “stealing” issue). Again: I’m not sure what help KRAD could provide to avoid this situation but it’s so easy to forget and cause problems that if there was a way to fix it, I think it would be very helpful for all of the client applications.
            {quote}

            At this time, it looks like we are clearing the basic primary keys but do not have the code to clear all keys associated with the maintenance document, like those on collections or those on child objects. We should be doing this if {{preserveLockingKeysOnCopy}} is not set. Verify whether this is still a problem in KRAD and fix it if it is. May also need to apply fixes to versions greater than 2.1.
            Reported via James Smith:

            {quote}
            About a month ago, I discovered an issue in TEM where a business object with children was being maintained on a maint doc. The business object itself and more importantly, the collection of children objects, all used synthetic keys based on a sequence as their PK’s, and on copy, I found we had to clear the PK’s manually in the processAfterCopy on the maintainable so that the PK’s were reassigned with the document saved them again; if we didn’t do the key clearing, then the children business objects were “stolen” by the object created by the copy and removed from the original. I talked to Doug Pace to see what KC did about this, and he saw two examples of this: one where they cleared the keys and one where they had forgotten (causing the “stealing” issue). Again: I’m not sure what help KRAD could provide to avoid this situation but it’s so easy to forget and cause problems that if there was a way to fix it, I think it would be very helpful for all of the client applications.
            {quote}

            At this time, it looks like we are clearing the basic primary keys but do not have the code to clear all keys associated with the maintenance document, like those on collections or those on child objects. We should be doing this if {{preserveLockingKeysOnCopy}} is not set. Verify whether this is still a problem in KRAD and fix it if it is.
            cniesen Claus Niesen made changes -
            Sprint Middleware 2.5.2 Sprint 3 [ 433 ] Middleware 2.5.2 Sprint 4 [ 436 ]
            jruch Jeff Ruch made changes -
            Assignee Jeff Ruch [ jruch ]
            jruch Jeff Ruch made changes -
            Sprint Middleware 2.5.2 Sprint 4 [ 436 ] Middleware 2.5.2 Sprint 3 [ 433 ]
            jruch Jeff Ruch made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            cniesen Claus Niesen made changes -
            Sprint Middleware 2.5.2 Sprint 3 [ 433 ] Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4 [ 433, 436 ]
            cniesen Claus Niesen made changes -
            Rank Ranked higher
            Hide
            jruch Jeff Ruch added a comment - - edited

            The basic primary keys are being cleared out in maintenanceDocumentServiceImpl$processMaintenanceObjectForCopy in clearPrimaryKeyFields()

            Show
            jruch Jeff Ruch added a comment - - edited The basic primary keys are being cleared out in maintenanceDocumentServiceImpl$processMaintenanceObjectForCopy in clearPrimaryKeyFields()
            Hide
            jruch Jeff Ruch added a comment -

            Hi James,

            Looking at the example above, you have it hard-coded for setting the AgencyStagingDataId to null. I assume this shouldn't be done to all foreign keys. What is the rule, or how do I determine which foreign keys should be set to null?

            Show
            jruch Jeff Ruch added a comment - Hi James, Looking at the example above, you have it hard-coded for setting the AgencyStagingDataId to null. I assume this shouldn't be done to all foreign keys. What is the rule, or how do I determine which foreign keys should be set to null?
            jruch Jeff Ruch logged work - 12/Jan/15 1:56 PM
            • Time Spent:
              2 hours
               
              Researched issue.
            jruch Jeff Ruch made changes -
            Remaining Estimate 2 days [ 57600 ] 1 day, 6 hours [ 50400 ]
            Time Spent 2 hours [ 7200 ]
            Worklog Id 100614 [ 100614 ]
            jruch Jeff Ruch made changes -
            Status In Progress [ 3 ] Open [ 1 ]
            Hide
            jksmith James Smith added a comment - - edited

            Adding the OJB declaration for AgencyStagingData to help explain my answer better:

            <class-descriptor class="org.kuali.kfs.module.tem.businessobject.AgencyStagingData" table="TEM_AGENCY_STAGING_T">
            		<field-descriptor name="id" primarykey="true" column="ID" jdbc-type="INTEGER"/>
            		<field-descriptor name="copiedFromId" column="COPIED_AGENCY_STAGING_ID" jdbc-type="INTEGER"/>
            		<field-descriptor name="errorCode" column="ERROR_CD" jdbc-type="VARCHAR"/>
            		<field-descriptor name="duplicateRecordId" column="DUP_REC_ID" jdbc-type="INTEGER"/>
            		<field-descriptor name="importBy" column="IMPORT_BY" jdbc-type="VARCHAR"/>  	    
                    	    
            		<collection-descriptor name="tripAccountingInformation" element-class-ref="org.kuali.kfs.module.tem.businessobject.TripAccountingInformation" collection-class="org.apache.ojb.broker.util.collections.RemovalAwareList" auto-retrieve="true" auto-update="object" auto-delete="true">
            			<inverse-foreignkey field-ref="agencyStagingDataId"/>
            		</collection-descriptor>
            		
                    <reference-descriptor name="profile" class-ref="org.kuali.kfs.module.tem.businessobject.TemProfile" auto-retrieve="true" auto-update="none" auto-delete="none">
                        <foreignkey field-ref="temProfileId"/>
                    </reference-descriptor>
                    
                    <reference-descriptor name="creditCardAgency" class-ref="org.kuali.kfs.module.tem.businessobject.CreditCardAgency" auto-retrieve="true" auto-update="none" auto-delete="none">
                        <foreignkey field-ref="creditCardOrAgencyCode"/>
                    </reference-descriptor>
                    
                    <reference-descriptor name="searchChart" class-ref="org.kuali.kfs.coa.businessobject.Chart" auto-retrieve="true" auto-update="none" auto-delete="none" proxy="true">
            	        <foreignkey field-ref="searchChartOfAccountsCode" />
            	    </reference-descriptor>
            	
            	    <reference-descriptor name="searchAccount" class-ref="org.kuali.kfs.coa.businessobject.Account" auto-retrieve="true" auto-update="none" auto-delete="none" proxy="true">
            	        <foreignkey field-ref="searchChartOfAccountsCode" />
            	        <foreignkey field-ref="searchAccountNumber" />
            	    </reference-descriptor>
            	
            	    <reference-descriptor name="searchSubAccount" class-ref="org.kuali.kfs.coa.businessobject.SubAccount" auto-retrieve="true" auto-update="none" auto-delete="none" proxy="true">
            	        <foreignkey field-ref="searchChartOfAccountsCode" />
            	        <foreignkey field-ref="searchAccountNumber" />
            	        <foreignkey field-ref="searchSubAccountNumber" />
            	    </reference-descriptor>
            	    
            	    <reference-descriptor name="agencyServiceFee" class-ref="org.kuali.kfs.module.tem.businessobject.AgencyServiceFee" auto-retrieve="true" auto-update="none" auto-delete="none">
            	    	<foreignkey field-ref="distributionCode"/>
            	    </reference-descriptor>	    
            	</class-descriptor>
            

            I actually removed several field descriptors because they're kind of irrelevant and there's a ton of them...

            And here's TripAccountingInformation:

            	<class-descriptor class="org.kuali.kfs.module.tem.businessobject.TripAccountingInformation" table="TEM_TRP_ACCT_INFO_T">
            		<field-descriptor name="id" primarykey="true" sequence-name="TEM_TRP_ACCT_INFO_ID_SEQ" autoincrement="true" column="id" jdbc-type="INTEGER"/>
            		<field-descriptor name="agencyStagingDataId" column="AGENCY_ID" jdbc-type="INTEGER"/>
            		<field-descriptor name="tripChartCode" column="FIN_COA_CD" jdbc-type="VARCHAR"/>
            		<field-descriptor name="tripAccountNumber" column="ACCT_NBR" jdbc-type="VARCHAR"/>
            		<field-descriptor name="tripSubAccountNumber" column="SUB_ACCT_NBR" jdbc-type="VARCHAR"/>
            		<field-descriptor name="objectCode" column="OBJ_CD" jdbc-type="VARCHAR"/>
            		<field-descriptor name="subObjectCode" column="SUB_OBJ_CD" jdbc-type="VARCHAR"/>
            		<field-descriptor name="projectCode" column="PRJ_CD" jdbc-type="VARCHAR"/>
            		<field-descriptor name="organizationReference" column="ORG_REF" jdbc-type="VARCHAR"/>
            		<field-descriptor name="amount" column="AMOUNT" jdbc-type="DECIMAL" conversion="org.kuali.rice.core.framework.persistence.ojb.conversion.OjbKualiDecimalFieldConversion"/>
            		<field-descriptor name="objectId" column="OBJ_ID" jdbc-type="VARCHAR"/>
            		<field-descriptor name="versionNumber" locking="true" column="VER_NBR" jdbc-type="BIGINT"/>
            		
            	    <reference-descriptor name="account" class-ref="org.kuali.kfs.coa.businessobject.Account" auto-retrieve="true" auto-update="none" auto-delete="none" proxy="true">
                        <foreignkey field-ref="tripChartCode" />
                        <foreignkey field-ref="tripAccountNumber" />
                    </reference-descriptor>
                
                    <reference-descriptor name="subAccount" class-ref="org.kuali.kfs.coa.businessobject.SubAccount" auto-retrieve="true" auto-update="none" auto-delete="none" proxy="true">
                        <foreignkey field-ref="tripChartCode" />
                        <foreignkey field-ref="tripAccountNumber" />
                        <foreignkey field-ref="tripSubAccountNumber" />
                    </reference-descriptor>
                    
                    <reference-descriptor name="project" class-ref="org.kuali.kfs.coa.businessobject.ProjectCode" auto-retrieve="true" auto-update="none" auto-delete="none" proxy="true">
                    	<foreignkey field-ref="projectCode" />
                    </reference-descriptor>
                    
            	</class-descriptor>
            
            Show
            jksmith James Smith added a comment - - edited Adding the OJB declaration for AgencyStagingData to help explain my answer better: <class-descriptor class= "org.kuali.kfs.module.tem.businessobject.AgencyStagingData" table= "TEM_AGENCY_STAGING_T" > <field-descriptor name= "id" primarykey= "true" column= "ID" jdbc-type= "INTEGER" /> <field-descriptor name= "copiedFromId" column= "COPIED_AGENCY_STAGING_ID" jdbc-type= "INTEGER" /> <field-descriptor name= "errorCode" column= "ERROR_CD" jdbc-type= "VARCHAR" /> <field-descriptor name= "duplicateRecordId" column= "DUP_REC_ID" jdbc-type= "INTEGER" /> <field-descriptor name= "importBy" column= "IMPORT_BY" jdbc-type= "VARCHAR" /> <collection-descriptor name= "tripAccountingInformation" element-class-ref= "org.kuali.kfs.module.tem.businessobject.TripAccountingInformation" collection-class= "org.apache.ojb.broker.util.collections.RemovalAwareList" auto-retrieve= "true" auto-update= "object" auto-delete= "true" > <inverse-foreignkey field-ref= "agencyStagingDataId" /> </collection-descriptor> <reference-descriptor name= "profile" class-ref= "org.kuali.kfs.module.tem.businessobject.TemProfile" auto-retrieve= "true" auto-update= "none" auto-delete= "none" > <foreignkey field-ref= "temProfileId" /> </reference-descriptor> <reference-descriptor name= "creditCardAgency" class-ref= "org.kuali.kfs.module.tem.businessobject.CreditCardAgency" auto-retrieve= "true" auto-update= "none" auto-delete= "none" > <foreignkey field-ref= "creditCardOrAgencyCode" /> </reference-descriptor> <reference-descriptor name= "searchChart" class-ref= "org.kuali.kfs.coa.businessobject.Chart" auto-retrieve= "true" auto-update= "none" auto-delete= "none" proxy= "true" > <foreignkey field-ref= "searchChartOfAccountsCode" /> </reference-descriptor> <reference-descriptor name= "searchAccount" class-ref= "org.kuali.kfs.coa.businessobject.Account" auto-retrieve= "true" auto-update= "none" auto-delete= "none" proxy= "true" > <foreignkey field-ref= "searchChartOfAccountsCode" /> <foreignkey field-ref= "searchAccountNumber" /> </reference-descriptor> <reference-descriptor name= "searchSubAccount" class-ref= "org.kuali.kfs.coa.businessobject.SubAccount" auto-retrieve= "true" auto-update= "none" auto-delete= "none" proxy= "true" > <foreignkey field-ref= "searchChartOfAccountsCode" /> <foreignkey field-ref= "searchAccountNumber" /> <foreignkey field-ref= "searchSubAccountNumber" /> </reference-descriptor> <reference-descriptor name= "agencyServiceFee" class-ref= "org.kuali.kfs.module.tem.businessobject.AgencyServiceFee" auto-retrieve= "true" auto-update= "none" auto-delete= "none" > <foreignkey field-ref= "distributionCode" /> </reference-descriptor> </class-descriptor> I actually removed several field descriptors because they're kind of irrelevant and there's a ton of them... And here's TripAccountingInformation: <class-descriptor class= "org.kuali.kfs.module.tem.businessobject.TripAccountingInformation" table= "TEM_TRP_ACCT_INFO_T" > <field-descriptor name= "id" primarykey= "true" sequence-name= "TEM_TRP_ACCT_INFO_ID_SEQ" autoincrement= "true" column= "id" jdbc-type= "INTEGER" /> <field-descriptor name= "agencyStagingDataId" column= "AGENCY_ID" jdbc-type= "INTEGER" /> <field-descriptor name= "tripChartCode" column= "FIN_COA_CD" jdbc-type= "VARCHAR" /> <field-descriptor name= "tripAccountNumber" column= "ACCT_NBR" jdbc-type= "VARCHAR" /> <field-descriptor name= "tripSubAccountNumber" column= "SUB_ACCT_NBR" jdbc-type= "VARCHAR" /> <field-descriptor name= "objectCode" column= "OBJ_CD" jdbc-type= "VARCHAR" /> <field-descriptor name= "subObjectCode" column= "SUB_OBJ_CD" jdbc-type= "VARCHAR" /> <field-descriptor name= "projectCode" column= "PRJ_CD" jdbc-type= "VARCHAR" /> <field-descriptor name= "organizationReference" column= "ORG_REF" jdbc-type= "VARCHAR" /> <field-descriptor name= "amount" column= "AMOUNT" jdbc-type= "DECIMAL" conversion= "org.kuali.rice.core.framework.persistence.ojb.conversion.OjbKualiDecimalFieldConversion" /> <field-descriptor name= "objectId" column= "OBJ_ID" jdbc-type= "VARCHAR" /> <field-descriptor name= "versionNumber" locking= "true" column= "VER_NBR" jdbc-type= "BIGINT" /> <reference-descriptor name= "account" class-ref= "org.kuali.kfs.coa.businessobject.Account" auto-retrieve= "true" auto-update= "none" auto-delete= "none" proxy= "true" > <foreignkey field-ref= "tripChartCode" /> <foreignkey field-ref= "tripAccountNumber" /> </reference-descriptor> <reference-descriptor name= "subAccount" class-ref= "org.kuali.kfs.coa.businessobject.SubAccount" auto-retrieve= "true" auto-update= "none" auto-delete= "none" proxy= "true" > <foreignkey field-ref= "tripChartCode" /> <foreignkey field-ref= "tripAccountNumber" /> <foreignkey field-ref= "tripSubAccountNumber" /> </reference-descriptor> <reference-descriptor name= "project" class-ref= "org.kuali.kfs.coa.businessobject.ProjectCode" auto-retrieve= "true" auto-update= "none" auto-delete= "none" proxy= "true" > <foreignkey field-ref= "projectCode" /> </reference-descriptor> </class-descriptor>
            Hide
            jksmith James Smith added a comment -

            Okay, so in the AgencyStagingData example, I clear out tripAccountingInformation because a) it has a synthetic key and b) the relationship of AgencyStagingData to TripAccountingInformation is such that when AgencyStagingData is saved, I know that TripAccountingInformation is saved as well. So that's why when I copy AgencyStagingData, I clear out the id's there.

            Having said that, I'm beginning to think that clearing out the agencyStagingId is kind of a mistake. Theoretically, TripAccountingInformation should have a relationship back to its parent object so that ojb can set that id. (The agencyStagingId is probably set manually somewhere else in the maintainable...I'd better check that...but if the ORM mapping had been done right, that shouldn't have been an issue.) In that case, ideally, you'd be able to find a relationship on the child object which points back to the parent object which is being copied, and you'd be able to clear out the key there.

            Am I making sense? I'm kind of sick today so apologies if I'm unclear.

            Show
            jksmith James Smith added a comment - Okay, so in the AgencyStagingData example, I clear out tripAccountingInformation because a) it has a synthetic key and b) the relationship of AgencyStagingData to TripAccountingInformation is such that when AgencyStagingData is saved, I know that TripAccountingInformation is saved as well. So that's why when I copy AgencyStagingData, I clear out the id's there. Having said that, I'm beginning to think that clearing out the agencyStagingId is kind of a mistake. Theoretically, TripAccountingInformation should have a relationship back to its parent object so that ojb can set that id. (The agencyStagingId is probably set manually somewhere else in the maintainable...I'd better check that...but if the ORM mapping had been done right, that shouldn't have been an issue.) In that case, ideally, you'd be able to find a relationship on the child object which points back to the parent object which is being copied, and you'd be able to clear out the key there. Am I making sense? I'm kind of sick today so apologies if I'm unclear.
            Hide
            jksmith James Smith added a comment -

            Oh - actually OJB probably knows to fill in agency staging data because of the inverse-foreignkey from its mapping for the collection of TripAccountingInformation objects. So yeah...that should be easy to find and clear as well.

            Sorry for OJB mappings - KFS hasn't moved to JPA yet - but I am certain there are JPA ways to derive this information as well if need be.

            Show
            jksmith James Smith added a comment - Oh - actually OJB probably knows to fill in agency staging data because of the inverse-foreignkey from its mapping for the collection of TripAccountingInformation objects. So yeah...that should be easy to find and clear as well. Sorry for OJB mappings - KFS hasn't moved to JPA yet - but I am certain there are JPA ways to derive this information as well if need be.
            Hide
            jruch Jeff Ruch added a comment -

            Thanks. I think I got it. Let me play around with it. First day back from the flu for me, so I'm a little fuzzy today as well. Thanks again.

            Show
            jruch Jeff Ruch added a comment - Thanks. I think I got it. Let me play around with it. First day back from the flu for me, so I'm a little fuzzy today as well. Thanks again.
            Hide
            jksmith James Smith added a comment -

            Totally understood re: the flu. Winter sucks. Thank you Jeff!

            Show
            jksmith James Smith added a comment - Totally understood re: the flu. Winter sucks. Thank you Jeff!
            jruch Jeff Ruch made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Hide
            jruch Jeff Ruch added a comment -

            My understanding is that items with: auto-retrieve="true" , auto-update="object" , auto-delete="true" with an inverse foreign key in OJB need to have their pk cleared on copy if preserveLockingKeysOnCopy is not set.

            Show
            jruch Jeff Ruch added a comment - My understanding is that items with: auto-retrieve="true" , auto-update="object" , auto-delete="true" with an inverse foreign key in OJB need to have their pk cleared on copy if preserveLockingKeysOnCopy is not set.
            Hide
            jksmith James Smith added a comment -

            I'm wondering if just auto-update would be the necessary criteria there. Certainly auto-retrieve is irrelevant. And I can imagine child objects inactivating instead of actually deleting, ie the auto-delete may not always convey child-objectness.

            Show
            jksmith James Smith added a comment - I'm wondering if just auto-update would be the necessary criteria there. Certainly auto-retrieve is irrelevant. And I can imagine child objects inactivating instead of actually deleting, ie the auto-delete may not always convey child-objectness.
            Hide
            jksmith James Smith added a comment -

            Added Jonathan as watcher to see if he agrees with my comment just made.

            Show
            jksmith James Smith added a comment - Added Jonathan as watcher to see if he agrees with my comment just made.
            Hide
            jksmith James Smith added a comment -

            And added Douglas Pace, too, since he saw the KC versions of these, to see if he agrees with my assessment above. Thank you Jonathan and Doug!

            Show
            jksmith James Smith added a comment - And added Douglas Pace, too, since he saw the KC versions of these, to see if he agrees with my assessment above. Thank you Jonathan and Doug!
            Hide
            jruch Jeff Ruch added a comment -

            I agree that auto-retrieve="true" is irrelevant. If I just check for auto-update, I'm assuming it will cover auto-delete. Is there ever a case where you configure auto-delete, without auto-update? Curious on what others have to say.

            Show
            jruch Jeff Ruch added a comment - I agree that auto-retrieve="true" is irrelevant. If I just check for auto-update, I'm assuming it will cover auto-delete. Is there ever a case where you configure auto-delete, without auto-update? Curious on what others have to say.
            Hide
            jksmith James Smith added a comment -

            An auto-delete without an auto-update seems like...something would be wrong in the modelling. I can't think of an example off hand.

            Show
            jksmith James Smith added a comment - An auto-delete without an auto-update seems like...something would be wrong in the modelling. I can't think of an example off hand.
            Hide
            dpace Douglas Pace added a comment -

            I'm not sure if we've seen this in maint docs as we don't have many with child records, but we have frequently seen this in our trans docs when we allow copies or versioning. The new dataObjectService.copyInstance seems to handle this for us thus far.

            Show
            dpace Douglas Pace added a comment - I'm not sure if we've seen this in maint docs as we don't have many with child records, but we have frequently seen this in our trans docs when we allow copies or versioning. The new dataObjectService.copyInstance seems to handle this for us thus far.
            Hide
            jkeller Jonathan Keller added a comment -

            Yes - just checking for auto-update would be correct on this one.

            Delete without update - yes, that would be odd. Only situation I can think of that being used (auto-delete=yes,auto-update=no) is if you really needed to control when the child objects were updated. (But that had no purpose without their parent.)

            Show
            jkeller Jonathan Keller added a comment - Yes - just checking for auto-update would be correct on this one. Delete without update - yes, that would be odd. Only situation I can think of that being used (auto-delete=yes,auto-update=no) is if you really needed to control when the child objects were updated. (But that had no purpose without their parent.)
            cniesen Claus Niesen made changes -
            Sprint Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4 [ 433, 436 ] Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4, Middleware 2.5.2 Sprint 5 [ 433, 436, 451 ]
            cniesen Claus Niesen made changes -
            Rank Ranked higher
            jruch Jeff Ruch made changes -
            Link This issue cloned to KULRICE-14154 [ KULRICE-14154 ]
            jruch Jeff Ruch made changes -
            Status In Progress [ 3 ] Open [ 1 ]
            jruch Jeff Ruch made changes -
            Assignee Jeff Ruch [ jruch ]
            cniesen Claus Niesen made changes -
            Sprint Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4, Middleware 2.5.2 Sprint 5 [ 433, 436, 451 ] Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4, Middleware 2.5.2 Sprint 5, Rice 2.6.0-M1 Sprint 1 [ 433, 436, 451, 455 ]
            cniesen Claus Niesen made changes -
            Rank Ranked higher
            cniesen Claus Niesen made changes -
            Sprint Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4, Middleware 2.5.2 Sprint 5, Rice 2.6.0-M1 Sprint 1 [ 433, 436, 451, 455 ] Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4, Middleware 2.5.2 Sprint 5 [ 433, 436, 451 ]
            cniesen Claus Niesen made changes -
            Rank Ranked lower
            cniesen Claus Niesen made changes -
            Labels MidTerm
            ewestfal Eric Westfall made changes -
            Rank Ranked lower
            cniesen Claus Niesen made changes -
            Fix Version/s 2.1.11 [ 17969 ]
            Fix Version/s 2.1.10 [ 17909 ]
            cniesen Claus Niesen made changes -
            Fix Version/s 2.1.11 [ 17969 ]
            ewestfal Eric Westfall made changes -
            Labels MidTerm LongTerm

              People

              • Assignee:
                Unassigned
                Reporter:
                jksmith James Smith
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - 2 days
                  2d
                  Remaining:
                  Time Spent - 2 hours Remaining Estimate - 1 day, 6 hours
                  1d 6h
                  Logged:
                  Time Spent - 2 hours Remaining Estimate - 1 day, 6 hours
                  2h