Hi Dmitri, hi all,
> move the `@MeterTag(key="realm_id",expression="realmIdentifier")` annotation
> to the method level.
I tried that as well, and even if it's possible to place the
annotation at method level, it seems that doing so is not supported:
the expression resolver doesn't get invoked a
Hi Dmitri,
Thanks a lot for the clarification! I didn't realize
PolarisMetaStoreManager is a request-scoped bean.
I have to say that the whole implementation is kind of confusing. Although
I do agree that those
*MetastoreManagerImpl is not needed after the request ends, i am afraid
things may not
I'd prefer to avoid having the APIs reflect the scope of the implementation
beans under the hood. On the other hand, I don't like forcing methods at
the bottom of the call stack requiring parameters because they're necessary
later on. I liked passing CallContext around because it didn't really
matt
Thanks for stating your concerns, Yun!
Re: MetastoreManager, I believe the current state of that code is actually
the source of confusion and I'm trying to clarify that.
For example, TransactionalMetaStoreManagerImpl is currently created per
realm. However, this class does not carry any state. It
Hi Dmitri,
Thanks for bringing that up!
I am not an expert with CDI, based my recent experience with CDI, while CDI
does help making development
simpler under many cases, it does also make things more complicated under
some scenarios. Especially when
injecting a request scoped object into applica
Agreed with Alex. I think passing a realm context is a cleaner solution
than injecting a request scope realm context. CDI provides a lot of
benefits, but it doesn't mean that we should alway use it.
In general, injecting a request-scoped bean into an application-scoped bean
is perfectly valid in C
Thanks, Alex! Very good points!
Re: metrics, I did a quick POC by adding `@Inject RealmContext rc`
to QuarkusValueExpressionResolver and it appears to work. That
is, QuarkusValueExpressionResolver can get the realm ID from the injected
RealmContext as opposed to the API parameter.
With that, we c
Hi Dmitri,
Thanks for bringing up this important topic.
I generally agree with your refactoring proposal, but with 2 caveats:
1) For an application-scoped bean exposing methods to retrieve realm-scoped
components (e.g., the "factory" beans that expose methods like
"getOrCreateXYZ") I think it's
An example "skew" in current code: IcebergCatalogAdapter gets RealmContext
injected as a field, but also as a method parameters in createNamespace().
On Thu, Jun 5, 2025 at 8:35 PM Dmitri Bourlatchkov wrote:
> Hi All,
>
> Recently a few runtime issues related to the resolution of RealmContex got
