Re: MaterializationService.THREAD_INSTANCE vs INSTANCE
Yes, this is a bug. Unfortunately, it's a bug with the Cassandra adapter as
well. Sometimes it will fail to register the materialized view. I don't
believe anyone has come up with a good approach to fix this yes.
Le mer. 26 sept. 2018 à 13:54, Luis Fernando Kauer
<firstname.lastname@example.org> a écrit :
> I'm trying to use Calcite to optimize queries rewriting the queries to use
> materialized views.
> First, I found the following doc page about materialization in Calcite
> website by googling but I coudn't find a link to it in Calcite's website.
> Anyway, it does not explain how to add materialized views to the schema.
> I'm trying to follow how Cassandra Adapter does it. It uses de
> Hook.TRIMMED to be called to add the materialized views.
> Is that the recommended approach?
> I noticed that MaterializationService.instance() first tries to get an
> instance from a ThreadLocal field (THREAD_INSTANCE) and if it is null then
> uses the field instance (INSTANCE). The comments in the class says that
> ThreadLocal instance is supposed to be used for testing.
> However, THREAD_INSTANCE field is initialized with
> ThreadLocal.withInitial(MaterializationService::new), so it seems that it
> will never be null, making instance() method always return the
> THREAD_INSTANCE instance.
> The problem is that I'm running the statements in worker threads and
> sometimes the materialized view is used and sometimes not. I think the
> problem is that the materialization is not available when running in a
> different thread.
> Is that a bug?
> Any tips on how to add materialized views to an AbstractSchema?
> Luis Fernando