Hi Yuan,
I’m fine to skip the OneToManyCache since it’s just a one-line implementation
under the abstraction of cache. Thanks for the review and advice.
Qingsheng
> On Apr 14, 2022, at 19:23, zst...@163.com wrote:
>
> Hi Qingsheng,
>
>
>
>
> Thanks very much for your detail advice. The f
Hi Qingsheng,
Thanks very much for your detail advice. The first two points are very clear
and make sense. I have only one question about the third point.
>Another point to note is that if you check the usage of cache in JDBC and Hive
>lookup table, the value type is List, since it’s commo
Hi Yuan,
Sorry for pending such long time on this thread. I think adding unified
abstraction and metrics for cache is quite important for users and developers
to optimize and improve their jobs with lookup join. We also have our inner
cache abstraction and implementation, so I took a deeper obs
Hi Qingsheng,
Sorry for my wrong format.
> If I understand correctly these are specified in DDL table options by users.
It's inconvenient for user to checkout the options when they in front of a
running task. And they don't know the real underlying options in effect if
there are some bugs or
Hi Qingsheng,
> If I understand correctly these are specified in DDL table options by users.
It's inconvenient for user to checkout the options when they in front of a
running task. And they don't know the real underlying options in effect if
there are some bugs or other incorrect configur
Hi Yuan,
> how can we tell the real “identifier” and “type” options in effect to users?
If I understand correctly these are specified in DDL table options by users.
For example:
CREATE TABLE DimTable (…) WITH (
...
“cache.identifier” = “guava”,
“cache.type” = “LRU”
);
> Does Me
Hi Qingsheng Ren,
Thanks for your feedback.
> 1. It looks like “identifier” and “type” are options of cache instead of
> metrics. I think they are finalized once the cache is created so maybe it’s
> not quite helpful to report them to the metric system.
Maybe it's not quite appropriate to rep
Hi Yuan,
Thanks for raising this discussion! I believe this will be very helpful for
lookup table developers, and standardizing metrics would be essential for
users to tuning their systems.
Here’s some thoughts in my mind:
1. It looks like “identifier” and “type” are options of cache instea
Hi devs,
I would like to propose a discussion thread about abstraction of Cache
LookupFunction with metrics for cache in connectors to make cache out of box
for connector developers. There are multiple LookupFunction implementations in
individual connectors [1][2][3][4] so far.
At the same ti
