Got a bit of a problem whereby I need to perform some validation during processing of an update delta, specifically in a BeforeProcessChange handler.
The issue i have is that the SQL I’m trying to execute as part of my validation (which I’ve placed in a command in the schema) is blocking because it’s accessing the same table as the update but is obviously using a separate transaction, so everything locks up.
What I need is to execute this SQL command in the context of the same transaction that the update processing is using. Any ideas on how I can achieve this?
I think I may have figured it out. The problem is that my code which is executing the command is creating a fresh service instance which has its own transaction.
What I need to do is make this service instance use the same transaction as the existing instance being used by the update process.
I have access to the service via the Sender.Service in the BeforeProcessChange handler so I should be able to pass this to my command execution code and make it use that. I’ll give it a go.
Yes I could do that, the only reason I don’t is code organisation - I’ve got all my validation functions elsewhere so I just need to pass the right context to them.
I’m also using the same validation functions for both client and server as much of the checks are the same but with some differences, so I call them both from within the change processing event handlers but also within my client OnBeforePost and OnBeforeDelete handlers as some things can be checked before attempting to apply the updates. I think I just need to pass some more context to the functions when called from the change processing handlers so they operate within the context of the existing service instance.
I think a lot of this logic can actually be cleaned up but I’ve not got round to it yet.
I think, when I originally started writing this several years ago, I had the bright idea of a single validation function for each table which could be called either client-side (i.e. OnBeforePost etc) or server-side (BeforeProcessChange).
In reality it’s probably easier to have separate validation functions, one for the client for simple data validation checks and one for the server for more involved checks when applying the changes. The server logic could then be moved directly inside the change handlers for simplicity.