Skip to content

Conversation

@Hydrocharged
Copy link
Contributor

@Hydrocharged Hydrocharged commented Nov 13, 2025

This is an example of how we could implement a form of dependency injection via hooks. In Doltgres, we'll create our own hooks object that implements the interface, and all throughout the GMS codebase (in the relevant locations), we'd make these calls. We can tailor these calls as well, so it doesn't have to just be Pre/PostStatement, and we can have ones for intermediate steps as well. This can also be used for many of the free-floating functions that we're reassigning in Doltgres (although it may take a bit of reworking to prevent cycles).

Here are two examples:

  1. In Doltgres, we place a hook on table creation, renaming, and deletion, and use that to ensure that the table type properly follows renames and whatnot.
  2. When creating an extension, we can add a check in every hook that sees if some "in an extension script" flag has been set (perhaps in the Doltgres session). If it has, then we'll add a dependency between the extension and resulting object in the dependency tracker in Doltgres (which is similar to Postgres' pg_depend table).

I'm still looking into a better way of removing the singular global variable for defining hooks to ensure that they're available everywhere (engine isn't passed around everywhere, context has cycle issues, etc.), but I'm looking more for feedback on the general approach rather than such specifics.

@Hydrocharged Hydrocharged requested a review from zachmu November 13, 2025 15:55
@Hydrocharged
Copy link
Contributor Author

Also, right now tests are going to fail since they don't include the noop package so the global interface variable is nil, but that's irrelevant to what should be checked right now.

Copy link
Member

@zachmu zachmu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General idea is sound, but let's avoid introducing more globals if we can help it


// Global is a variable that contains the interface for calling hooks. By default, this contains no-op hooks as
// integrators may implement their own hooks. This variable should be overwritten by the integrator.
var Global Hooks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rest of the interface is fine, but we should avoid having a global here if at all possible. Instead, put this on the analyzer builder, and then it can be assigned to the session for use in the exec stuff.

// Hooks is an interface that represents various hooks that are called within a statement's lifecycle.
type Hooks interface {
// Table returns hooks related to direct table statements.
Table() Table
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these should probably be plural, returning either a slice of hooks or an iterator over them. We should assume that there is going to be a chain of hooks that integrators set up to run in some order they choose.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably just put this in noop.go in the same package as the defn

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants