Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uniform watchedTables interface for Selectables #3475

Open
jackd opened this issue Feb 14, 2025 · 2 comments
Open

Uniform watchedTables interface for Selectables #3475

jackd opened this issue Feb 14, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@jackd
Copy link

jackd commented Feb 14, 2025

I'm looking for a way to track table dependencies and the various watchedTables implementations look to be exactly what I'm after. Alas I can't seem to find a uniform interface for all selectables. I've hacked together a hodge-podge of functions that branch based on types, but if this is something that would be of interest to the project then I'd be happy to contribute something - in which case the PR is a request for guidance on API.

Current implementations:

Alternatively a uniform interface for selectables to generate GenerationContexts would also suffice.

@jackd jackd added the enhancement New feature or request label Feb 14, 2025
@simolus3
Copy link
Owner

I agree with this idea 👍

Alternatively a uniform interface for selectables to generate GenerationContexts would also suffice.

What's your use case of going from Selectable -> GenerationContext? Is this only to extract watched tables? We aren't using GenerationContext everywhere (it's not used for custom queries, for instance), but I'm thinking about adding an interface to represent built statements in the next drift version. We could make that available from Selectables.

@jackd
Copy link
Author

jackd commented Feb 16, 2025

What's your use case of going from Selectable -> GenerationContext? Is this only to extract watched tables?

Purely as a way to get watched tables, yes. I only mention this because I thought the deprecated implementation indicated this might be the direction things are heading in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants