Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Process commands so that WITH clause is always resolved before executing it #2436
Process commands so that WITH clause is always resolved before executing it #2436
Changes from 16 commits
540699b
79fcc76
4ece6b4
13c5b1b
4236d60
2bc4936
ce887f5
89eacab
0464da6
f016e76
8a302cd
1448f57
a94a918
d794358
624693a
6d818ee
4f70d76
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we should avoid leaking the service context out of the engine context. It leads to tangled code. The fact the engine/execution_context is internally using a service context is an implementation detail that shouldn't, IMHO, leak out of the interface.
It looks like you've added this so that
DefaultTopicInjector
can get hold of the service context from the engine, but you actually have the service context at the point you're trying to get the injector from the factory.Maybe just have the factory take both a
ServiceContext
andMetaStore
instance. Then you can just invoke via:I know it's tempting as its convienient as we already pass around the engine, but it feels wrong to expose it IMHO. Maybe I'm wrong, but it just smells to me. We should aim to keep this interface as succinct as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same instinct as you, in fact that was the way I originally had it. The problem was that not just any sandboxed service context needs to be used - it has to be exactly the same sandboxed context that the sandboxed engine uses. Otherwise it can't validate a sequence of statements that create topics, for example:
When command
0
runs, it updates the service context with a new topicY
withp
partitions andr
replicas. When command1
runs, it expects to be able to read from the topic forY
, but that topic doesn't exist.So, unfortunately, the coupling is an artifact of where the sandbox is created (deep inside the engine).
To do what you suggest, we can pipe in
ServiceContext
through theksqlEngine#createSandbox
, into the constructor forSandboxedExecutionContext
and then intoEngineContext#createSandbox
from every place we callcreateSandbox
.This isn't so bad, but it's tricky to get right (to make sure that we always use the same execution context as the engine we are using). As soon as I thought about that, I decided that it was appropriate to expose the service context because (as it stands) the coupling is actually an attribute of the engine, not just an implementation detail.
If you strongly disagree, I can do one of two things:
Optional<ServiceContext> getSandboxContext
which will only return if it is a sandbox (ew 🤢 )There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hummm... makes sense. let's see how it looks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The impersonation work that Sergio is doing will mean that each request to the engine will need to come with its own
ServiceContext
that runs things in the context of the initiating user.With that in mind, it probably makes sense to not expose the service context from the engine, but instead pass it each time.