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

Add a get-manifest API method (#2168) #2232

Merged
merged 1 commit into from
Mar 24, 2020

Conversation

beckjake
Copy link
Contributor

@beckjake beckjake commented Mar 23, 2020

resolves #2168

Description

When a user calls 'get-manifest', compile all the nodes in the project and return the compiled manifest from memory.

get-manifest takes no arguments.
'get-manifest' returns an async ID, just like the existing compile/run/etc. The final result will be an object with logs and manifest attributes.

See #2169 for the PR about slimming this down.

Checklist

  • I have signed the CLA
  • I have run this code in development and it appears to resolve the stated issue
  • This PR includes tests, or tests are not required/relevant for this PR
  • I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.

…roject and return the compiled manifest from memory.

'get-manifest' returns an async ID, just like the existing compile/run/etc
@drewbanin
Copy link
Contributor

@beckjake nice, this looks great!

One question: can we make this method block instead of running async? Here's what I'm thinking:

We want to use this method to render the dbt docs site. If this method is async, then we need to:

  1. call the method
  2. poll for a response
  3. write the response out to a file
  4. serve the index.html file for the docs site

If the method was blocking, then we could just proxy a request to get manifest.json to actually hit this endpoint on the dbt server.

I recognize that this method might be really slow for projects that contain a bunch of introspective queries. The thing I'm trying to figure out is: should the compilation be an async background process, or should the compilation happen directly when someone wants to view the docs represented in the state of a dbt server.

Curious to hear what you think! cc @cmcarthur

@beckjake
Copy link
Contributor Author

One question: can we make this method block instead of running async? Here's what I'm thinking:

We can, but I really don't recommend it. The process takes several seconds, probably minutes on huge projects. Web requests that block for minutes tend to get cut off by various timeout mechanisms along the network path and result in inscrutable network-y failures. If we want to return the manifest directly, we probably have to compile projects in the background on sighup, or something.

@drewbanin
Copy link
Contributor

Ok - I buy that - this is a good starting point and we can iterate on the exact interface in the future if need be

Copy link
Contributor

@drewbanin drewbanin left a comment

Choose a reason for hiding this comment

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

LGTM - let's ship it :)

@beckjake beckjake merged commit ca232db into dev/octavius-catto Mar 24, 2020
@beckjake beckjake deleted the feature/rpc-get-manifest branch March 24, 2020 13:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Write out manifest.json file when the RPC server is HUP'd
2 participants