populate the cache on compile, too (#1705)

[beckjake]

Fixes #1705

dbt compile will now populate the cache before the run, but after the manifest has been built, just like dbt run/dbt test already do.

I don't think dbt ls will need this as it doesn't compile nodes, it just compiles a manifest.

I didn't implement lazy-loading, though we could definitely also choose to lazy-load the cache on a per-schema basis. That would help if you had a project with many schemas and only a couple get_relation/is_incremental/similar calls.

[drewbanin]

Edit: wrong PR :)

[drewbanin]

Ok - I thought about this one a bunch more. How much is involved in lazily loading the relation cache? I think that this implementation is sort of a toss-up: it might make dbt compile faster for some projects and slower for others. It really does depend on 1) the proportion of schemas which get_relation() is called against and 2) the number of times that method is called against each particular schema.

Some examples:

• 1 schema, no calls to get_relation()
  • old: 0 queries
  • new: 1 query
• 1 schema, 10 calls to get_relation()
  • old: 10 queries
  • new: 1 query
• 5 schemas, 1 call to get_relation()
  • old: 1 query
  • new: 5 queries
• 5 schemas, 10 calls to get_relation()
  • old: 10 queries
  • new: 5 queries

So, it's not super clear that this will actually be better in the general case. If we're able to lazily populate the cache, then I do think that implementation would be strictly better than what we have in place currently.

If lazy loading is a significant project, then it might make sense to hold on that for now. Speeding up dbt compile is a worthwhile endeavor, but we don't necessarily have to do it right this moment.

[drewbanin]

closing this - see #1705