THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The semantic of the cache() / invalidateCache() API has gone through extended discussions. The rejected alternative semantics are documented below:
...
Rejected Option 1
API
Code Block | ||||
---|---|---|---|---|
| ||||
// Do not return anything void cache(); // Alternatively, return the original table for chaining purpose. Table cache(); // Physically uncache the table to release resource void uncache(); // To explicitly ignore cache, not part of this proposal but in the future Table hint(“ingoreCache”) |
...
Side effect: a table may be cached / uncached in a method invocation, while the caller does not know about this.
Code Block language java title Side Effect Option 1 { Table t = … // cache the table t.cache(); ... // The cache may be released in foo() foo(t); ... // cache is no longer available t.bar() } void foo(Table t) { // cache the table t.cache(); …. // Physically drop the table t.uncache(); }
...
Rejected Option 2
API
Code Block | ||||
---|---|---|---|---|
| ||||
// Return CachedTable CachedTable cache(); public interface CachedTable extends Table { // Physically uncache the table to release resource void uncache(); } |
...
Optimizer has no chance to kick in.
Users have to distinguish between original table / cached table.
Adding auto cache becomes a backward incompatible change.
...
Rejected Option 3
API
Code Block | ||||
---|---|---|---|---|
| ||||
// Return a CacheHandle CacheHandle cache(); public interface CacheHandle { // Physically release cache resource void release(); } |
...