init commit, tldr the cache_dir or files should probably indicate tab…

[jhnwu3]

The problem here is it can be quite confusing for the user to know exactly what tables are cached inside each cache file when they want to specify a new location.

[jhnwu3]

Don't know how to change this to a draft. But, will keep iterating on this as I move along.

[EricSchrock]

@jhnwu3 and @Logiquo I believe the updates I pushed fix both concerns while passing existing tests. I also added new tests for the new caching behavior. Let me know what you think.

1. Datasets with different configurations (root, tables, name, or dev value) get different caches.
2. Tasks with different configurations (names, schemas, or arg values) get different caches. Also, since default task caches are nested in dataset caches, running the same task on datasets with different configurations will result in different task caches, unless you override the default task cache path.

Maybe we feed the dataset UUID into the task UUID generation so that if someone overrides the default task path, task caching will still be sensitive to dataset configuration?

Or maybe we should remove the ability for users to override the default task cache? Do they really need to be able to override both the dataset and task cache paths?

[EricSchrock]

I think the one thing left is to update the benchmarking examples. Without the ability to set the task cache, the math for calculating cache usage needs to be updated.

[Logiquo]

LGTM, thanks @jhnwu3 @EricSchrock

[jhnwu3]

@EricSchrock I've updated benchmark scripts to use the correct cache_dir/tasks/ layout for calculating cache sizes. Let me know if this works.