EventHandler<T>
delegate, where T
is ulong
. The ID provided to the hook is the unique object ID of the triggering object. The sender is an object
that you can cast to a Task
that represents the asynchronous operation for the transaction that triggered the hook. Read more about how you can use this with a custom scheduler in the post-commit hooks with a custom scheduler section.DatabaseClass
in the code sample above is the database class that should trigger the hook when an instance from the class is inserted, updated, or deleted.AfterCommitInsert
hook for the Order
class. The reason for this is that the hooks are triggered based on the final result of the transaction, not the individual operations themselves. The only state change after the transaction was that the app created an Order
since the transaction created and then immediately deleted the Person
.ContinueWith
:Register
method and invoke this method in the entry point:DbTaskScheduler
. A complementary API can provide a custom scheduler when you register post-commit hooks, forcing Starcounter to utilize that instead of the built-in default. The example below shows a custom task scheduler that extends the Starcounter database task scheduler, executing a callback every time the hook in which it is installed in is queued:Hook<DatabaseClass>.OnAfterCommitInsert
Hook<DatabaseClass>.OnAfterCommitUpdate
Hook<DatabaseClass>.OnAfterCommitDelete