Making a BeforeDelete in a repository

[AbleMods]

Background:
When a stored credit card profile is deleted by the shopper, any payment record that references the deleted payment profile is not updated. The payment.GatewayPaymentProfileId value is still populated even though that entity ID no longer exists in ac_GatewayPaymentProfiles.

Since there's no foreign key constraint, my only other option seems to be creating a BeforeDelete override in the repository class.

This creates all sorts of problems later in life, especially when something simple like 'if (payment.PaymentProfile != null)' throws an nHibernate exception.

Solution:
So I added this method to the GatewayPaymentProfileRepository.cs file. See below.

My Question:
Is this the recommended way to do what is needed? I can't keep having ac_Payment records pointing to payment profiles that no longer exist. And I don't want to litter up my code with a bunch of try-catch.

Thoughts?

Code: Select all

        // BEGIN MOD: AbleMods.com
        // DATE:  02/01/2016
         
        /// <inheritdoc />
        public override void BeforeDelete(object entity)
        {
            // Cast the abstract object into a typed instance of the class 
            GatewayPaymentProfile profile = (GatewayPaymentProfile) entity;

            // Remove reference for any payments associates with this payment profile
            NHibernateHelper.CreateSQLQuery("UPDATE ac_Payments SET GatewayPaymentProfileId = NULL WHERE GatewayPaymentProfileId = :targetGatewayPaymentProfileId ")
                .SetInt32("targetGatewayPaymentProfileId ", profile.Id)
                .ExecuteUpdate();
        }
        // END MOD: AbleMods.com

[Katie]

I'm pretty sure we have this fixed now because it was assigned to me for final QA. I will check with Mazhar to make sure we are talking about the same issue though and see if he has any feedback on your proposed solution.

Thanks
Katie

[AbleMods]

Hey Thanks Katie !

I definitely would like to know so my solution doesn't conflict with yours. That would be bad

[mazhar]

Our fix is a two step fix. First we put some code against AfterDelete to update related payment records and set the profile id to null when profile is deleted. Secondly in maintenance service we have a piece of code to fix any existing records having invalid profile ids. The reason we choose to do it by code was due to nature of relationships between subscription, payments. Introducing database constraint for this may introduce multiple cascade paths which may lead to errors.

[AbleMods]

Understood. Thanks Mahzar!