Dmitri, that's a valid concern, but not for the H2 lib only. Every library introduced but not-used in production(e.g., test-only) could have CVEs. Do we have data showing that the H2 lib tends to have more CVEs than others?
Yufei On Wed, Jul 22, 2026 at 9:30 AM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yufei, > > The specific concerns were raised by Romain and Russell, as far as I can > tell. > > Repeating the links to those messages for convenience: [1], [2]. > > My personal interpretation is that it's not so much about CVEs that exist > today, but about something that may be discovered in the future and impact > the previously released Poalris images with the affected H2 driver > versions. > > From my POV, it's a valid concern given that H2 is not actually meant for > production use. > > WDYT? > > [1]: https://lists.apache.org/thread/jq41dpqoys551wf30qkf0wcwxssxo3qj > > [2]: https://lists.apache.org/thread/qdzb3lt8fwbpkjyd3lh07ylxr6wpwn1r > > Cheers, > Dmitri. > > On Tue, Jul 21, 2026 at 6:54 PM Yufei Gu <[email protected]> wrote: > > > Could you help me understand the security concern? Every library can have > > CVEs. Do you mean that the H2 library currently has unresolved CVEs, or > > that it has historically had more CVEs than other libraries? > > > > Yufei > > > > > > On Fri, Jul 17, 2026 at 11:18 AM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > Hi Yufei, > > > > > > What is your take on the security concerns associated with including > the > > H2 > > > JDBC driver in the standard Polaris images (highlighted by Alex in this > > > thread on Jul 3) [1]? > > > > > > [1] https://lists.apache.org/thread/8v42g3rvmt74b9s6ccgy7y8kky2hfbjo > > > > > > Thanks, > > > Dmitri. > > > > > > On Fri, Jul 17, 2026 at 2:06 PM Yufei Gu <[email protected]> wrote: > > > > > > > Hi Alex, > > > > > > > > Thanks for summarizing the discussion and separating the two > > questions. I > > > > think that helps move us toward consensus. > > > > > > > > First of all, I agree with the direction, but I'm not sure it's > urgent. > > > > TreeMapMetaStore isn't perfect, but we already have both JDBC + H2 > and > > > > NoSQL + in-memory in place. That should already satisfy most of test > > > > coverage. > > > > > > > > For question 1, I'd prefer Option 1a (JDBC + H2). > > > > > > > > My main reason is that it exercises the same persistence layer, > > > transaction > > > > handling, schema management, and configuration that most production > > > > deployments use. That gives us a better out of the box experience for > > > both > > > > users and developers, while also increasing confidence that what > works > > > > locally will behave similarly in production. > > > > > > > > Do we have to wait for either PR 4812 or 4984? I think bundling the > H2 > > > > driver should just unblock 1a. > > > > > > > > For question 2, I agree with handling test migration on a case by > case > > > > basis. Different tests have different goals, and using the most > > > appropriate > > > > backend for each test seems reasonable. > > > > > > > > Thanks, > > > > > > > > Yufei > > > > > > > > > > > > On Fri, Jul 17, 2026 at 10:45 AM Dmitri Bourlatchkov < > [email protected] > > > > > > > wrote: > > > > > > > > > Hi Alex, > > > > > > > > > > Option 1b certainly makes sense to me. I support going in that > > > direction. > > > > > > > > > > I'd propose opening a PR for that merging it before proceeding to > > test > > > > code > > > > > changes. > > > > > > > > > > In general, if 1b is acceptable, I'd think H2 should be removed [1] > > > from > > > > > tests and replaced with PostgreSQL or NoSQL InMemory. With that in > > > mind, > > > > > updating tests on a case-by-case basis seems reasonable to me. We > can > > > > > decide separately in each PR. > > > > > > > > > > [1] > https://lists.apache.org/thread/g1gg2w8hn9gvlmwrdh0x218whoh2wd39 > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > > > > > > On Fri, Jul 17, 2026 at 12:59 PM Alexandre Dutra < > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi Dmitri, hi all, > > > > > > > > > > > > Unfortunately I'm not sure your interpretation matches mine, so > > let's > > > > > > try to wrap up this discussion methodically. > > > > > > > > > > > > We agreed to deprecate TreeMapMetaStore for removal. But we > haven't > > > > > > reached consensus on two questions: > > > > > > > > > > > > 1) What should be the default metastore in the server image? > > > > > > 2) How to replace TreeMapMetaStore in tests? > > > > > > > > > > > > Question 1) is tricky and needs a clear decision. We have only > two > > > > > > options for a smooth UX (aka, "docker run apache/polaris" just > > > works): > > > > > > > > > > > > - Option 1a: JDBC+H2 > > > > > > - Option 1b: NoSQL+InMemory > > > > > > > > > > > > Option 1a is hard because it requires either my work on [4812] > > > > > > (runtime activated datasources) or Yufei's work on [4984] > > (unmanaged > > > > > > datasources). It also *requires* the H2 driver to be bundled by > > > > > > default, which some people are not comfortable with. In short, I > > > don't > > > > > > see this option being feasible any time soon. > > > > > > > > > > > > Therefore, I think option 1b is much easier, and that would be my > > > > > > preference. > > > > > > > > > > > > Question 2) is not as urgent, as I'm fairly sure we can find a > > > > > > solution as we go. I can see a few options: > > > > > > - Option 2a: migrate to JDBC+H2 > > > > > > - Option 2b: migrate to NoSQL+InMemory > > > > > > - Option 2c: decide on a case-by-case basis > > > > > > > > > > > > My personal preference would be 2c. > > > > > > > > > > > > Can we try to reach consensus on the two questions please? > > > > > > > > > > > > Thanks, > > > > > > Alex > > > > > > > > > > > > [4812]: https://github.com/apache/polaris/pull/4812 > > > > > > [4984]: https://github.com/apache/polaris/pull/4984 > > > > > > > > > > > > On Mon, Jul 6, 2026 at 8:29 PM Dmitri Bourlatchkov < > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > My interpretation of the discussion so far is that: > > > > > > > > > > > > > > 1) We do want to deprecate the TreeMap MetaStore for removal > > > > > > > > > > > > > > 2) JDBC + PostgreSQL should be used for testing as well as > NoSQL > > + > > > > > > MongoDB > > > > > > > (I believe it is in fact the case in current CI). > > > > > > > > > > > > > > 3) Instead of the TreeMap MetaStore, we will use the in-memory > > > NoSQL > > > > > > > MetaStore (for lightweight tests) > > > > > > > > > > > > > > Now, H2 becomes irrevant, IMHO, but removing it is being > > discussed > > > > > > > separately [1]. > > > > > > > > > > > > > > How does that sound? > > > > > > > > > > > > > > [1] > > > https://lists.apache.org/thread/g1gg2w8hn9gvlmwrdh0x218whoh2wd39 > > > > > > > > > > > > > > Thanks, > > > > > > > Dmitri. > > > > > > > > > > > > > > On Fri, Jul 3, 2026 at 5:25 AM Alexandre Dutra < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I'm confused: security concerns were previously raised here > [1] > > > and > > > > > > > > here [2] about bundling the H2 driver due to its past record > of > > > > > > > > critical CVEs. > > > > > > > > > > > > > > > > As a result, I assumed the JDBC+H2 option had been abandoned. > > Has > > > > > this > > > > > > > > proposal been brought back into consideration? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Alex > > > > > > > > > > > > > > > > [1]: > > > > > https://lists.apache.org/thread/jq41dpqoys551wf30qkf0wcwxssxo3qj > > > > > > > > [2]: > > > > > https://lists.apache.org/thread/qdzb3lt8fwbpkjyd3lh07ylxr6wpwn1r > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jul 3, 2026 at 8:54 AM Jean-Baptiste Onofré < > > > > [email protected] > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > Yeah fully agree and it was my point when I replied on the > > > thread > > > > > > > > > initially. > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > JB > > > > > > > > > > > > > > > > > > Le jeu. 2 juil. 2026 à 23:32, Yufei Gu < > [email protected] > > > > > > a > > > > > > écrit : > > > > > > > > > > > > > > > > > > > If our goal is to make the default experience closer to > > > > > production > > > > > > > > > > while removing TreeMap, then JDBC with H2 seems like a > more > > > > > natural > > > > > > > > > > choice. It exercises the same persistence layer, schema > > > > > management, > > > > > > > > > > and configuration that users will encounter in > production, > > > > while > > > > > > still > > > > > > > > > > keeping setup lightweight. > > > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 2, 2026 at 3:46 AM Alexandre Dutra < > > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Russell, > > > > > > > > > > > > > > > > > > > > > > The existing default metastore shouldn't be viewed > merely > > > as > > > > a > > > > > > > > > > > "relatively simple, self-contained implementation": it > > has > > > > > unique > > > > > > > > > > > quirks, such as returning result types that no other > > > > metastore > > > > > > does. > > > > > > > > > > > > > > > > > > > > > > Choosing the status quo simply to avoid making changes > is > > > > imho > > > > > > the > > > > > > > > > > > worst solution. > > > > > > > > > > > > > > > > > > > > > > Transitioning to the NoSQL metastore as the default > > > remains a > > > > > net > > > > > > > > > > > benefit, even if it is only used by 30% of the user > base. > > > > > > > > > > > > > > > > > > > > > > However, I agree with keeping the test suite on JDBC + > H2 > > > by > > > > > > default > > > > > > > > > > > if that ensures a higher level of confidence in our > tests > > > > > > ability to > > > > > > > > > > > reproduce real production setups. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 1, 2026 at 12:23 AM Russell Spitzer > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > I agree TreeMap and its associated transactional > stack > > > > should > > > > > > be > > > > > > > > > > deprecated. > > > > > > > > > > > > It’s test-only, confusing, and not used by JDBC > > > production > > > > > > paths. > > > > > > > > > > > > > > > > > > > > > > > > I’m less convinced that NoSQL + InMemory is a clearly > > > > > superior > > > > > > > > > > replacement > > > > > > > > > > > > for TreeMap in tests. At the storage layer it’s > > > essentially > > > > > the > > > > > > > > same > > > > > > > > > > class > > > > > > > > > > > > of > > > > > > > > > > > > thing: an in-memory, non-durable backend. The > > difference > > > > is > > > > > > that > > > > > > > > it > > > > > > > > > > > > exercises > > > > > > > > > > > > a completely different MetaStoreManager/persistence > > stack > > > > > > > > > > > > (NoSqlMetaStoreManager > > > > > > > > > > > > vs TransactionalMetaStoreManagerImpl), not the JDBC > > path > > > > most > > > > > > > > > > deployments > > > > > > > > > > > > use. It > > > > > > > > > > > > replaces a relatively simple, self-contained > > > implementation > > > > > > with > > > > > > > > > > something > > > > > > > > > > > > that is > > > > > > > > > > > > part of a much more complicated persistence stack, > > while > > > > > > remaining > > > > > > > > > > > > non-durable > > > > > > > > > > > > and test-only at the storage layer. > > > > > > > > > > > > > > > > > > > > > > > > For the problems originally raised (test-grade > > defaults, > > > > dead > > > > > > > > > > production > > > > > > > > > > > > path, developer confusion), > > > > > > > > > > > > JDBC + H2 seems like an actual fix. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 29, 2026 at 2:06 PM Dmitri Bourlatchkov < > > > > > > > > [email protected]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > > > > > > > > > I tend to agree that the DataSource discussion > > related > > > to > > > > > H2 > > > > > > > > became > > > > > > > > > > a bit > > > > > > > > > > > > > convoluted, and it's a lot simpler to use the NoSQL > > > > > in-memory > > > > > > > > > > persistence > > > > > > > > > > > > > instead. > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 29, 2026 at 1:57 PM Alexandre Dutra < > > > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Some updates on this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > I recently started a separate discussion > regarding > > > > > dynamic > > > > > > > > > > datasource > > > > > > > > > > > > > > activation at runtime [1]. This was intended as a > > > > > > prerequisite > > > > > > > > for > > > > > > > > > > > > > > adopting H2 as the default JDBC driver, as > > suggested > > > on > > > > > > this > > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, that proposal may end up being rejected. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Given this situation, we should reconsider our > > > options. > > > > > If > > > > > > the > > > > > > > > > > > > > > PostgreSQL + H2 approach is no longer a viable > > > > > replacement > > > > > > to > > > > > > > > the > > > > > > > > > > > > > > TreeMapMetaStore, I propose an alternative: let's > > use > > > > the > > > > > > NoSQL > > > > > > > > > > > > > > metastore with an InMemory backend. > > > > > > > > > > > > > > > > > > > > > > > > > > > > My reasoning is as follows: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. It remains a production-ready metastore, so > > > strictly > > > > > > > > superior to > > > > > > > > > > > > > > TreeMapMetaStore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. The metastore state update logic is the same > > > > > regardless > > > > > > of > > > > > > > > the > > > > > > > > > > > > > > backend, so we're still close to a real > production > > > > setup > > > > > > (same > > > > > > > > as > > > > > > > > > > with > > > > > > > > > > > > > > an in-memory JDBC driver). > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. It doesn't require any external dependencies > (no > > > > > bundled > > > > > > > > > > driver). > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd also note that while the NoSQL metastore is > > > already > > > > > > > > included > > > > > > > > > > > > > > today, it is not actionable because no backend is > > > > > > available. > > > > > > > > This > > > > > > > > > > goes > > > > > > > > > > > > > > against the onboarding UX that we're trying to > > > achieve, > > > > > as > > > > > > > > users > > > > > > > > > > > > > > interested in Polaris with the NoSQL metastore > > cannot > > > > > test > > > > > > this > > > > > > > > > > setup > > > > > > > > > > > > > > with the official image. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Therefore, I think NoSQL + InMemory would serve > as > > a > > > > more > > > > > > > > > > appropriate > > > > > > > > > > > > > > default setup for the official Polaris image. > > > > > > > > > > > > > > > > > > > > > > > > > > > > From what I see, it would boil down to adding one > > > line > > > > to > > > > > > > > > > > > > > polaris-server or polaris-service: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > runtimeOnly(project(":polaris-persistence-nosql-db-inmemory")) > > > > > > > > > > > > > > > > > > > > > > > > > > > > What are your thoughts on this? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > https://lists.apache.org/thread/jy6wb186h94n9q86kv01shbn68ppr6gv > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 19, 2026 at 12:07 PM Alexandre Dutra > < > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I wanted to give an update on this topic: I > have > > > > > started > > > > > > > > working > > > > > > > > > > on > > > > > > > > > > > > > > > this, but I would like to have [4812] merged > > first, > > > > > since > > > > > > > > that's > > > > > > > > > > a > > > > > > > > > > > > > > > prerequisite. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [4812]: > > > https://github.com/apache/polaris/pull/4812 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 5:15 PM Russell Spitzer > > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I believe the original idea of > TreeMapMetastore > > > was > > > > > > that it > > > > > > > > > > looked > > > > > > > > > > > > > very > > > > > > > > > > > > > > > > similar to FoundationDB from an API > > perspective, > > > > so > > > > > it > > > > > > > > served > > > > > > > > > > well > > > > > > > > > > > > > as > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > test system for the original backend being > > > > developed > > > > > > at SF. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree that H2 + JDBC makes sense to me now > > for > > > > the > > > > > > > > project. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 10:03 AM Alexandre > > Dutra > > > < > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you for your feedback. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There seems to be a general agreement on > the > > > idea > > > > > of > > > > > > > > > > deprecating > > > > > > > > > > > > > > > > > TreeMapMetaStore, coupled with the JDBC + > H2 > > > > > > solution for > > > > > > > > > > tests. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In most modules, the tests migration won't > > pose > > > > any > > > > > > > > serious > > > > > > > > > > > > > > > > > challenges, as replacing the metastore is > > > > generally > > > > > > just > > > > > > > > a > > > > > > > > > > matter > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > changing the configuration, and making sure > > the > > > > > > realm is > > > > > > > > > > properly > > > > > > > > > > > > > > > > > bootstrapped. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There will be, however, a few tricky > > situations > > > > in > > > > > > > > > > polaris-core: a > > > > > > > > > > > > > > few > > > > > > > > > > > > > > > > > tests rely on the TreeMapMetaStore, mostly > > as a > > > > > test > > > > > > > > > > convenience; > > > > > > > > > > > > > but > > > > > > > > > > > > > > > > > there is no obvious replacement for it in > > that > > > > > > module. I > > > > > > > > am > > > > > > > > > > however > > > > > > > > > > > > > > > > > confident that we can find a solution for > > that, > > > > > > either > > > > > > > > based > > > > > > > > > > on > > > > > > > > > > > > > > mocks, > > > > > > > > > > > > > > > > > or by bringing in a real metastore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If no objections are raised, I am going to > > > > prepare > > > > > a > > > > > > PR > > > > > > > > for > > > > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 3:28 PM Dmitri > > > > > Bourlatchkov < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for starting this thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also find the > > > > TransactionalMetaStoreManagerImpl > > > > > > and > > > > > > > > > > related > > > > > > > > > > > > > call > > > > > > > > > > > > > > paths > > > > > > > > > > > > > > > > > > conuising in Apache Polaris code. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I support promoting H2 to the default (in > > > > memory) > > > > > > > > > > Persistence > > > > > > > > > > > > > > backend for > > > > > > > > > > > > > > > > > > getting started cases. This should also > > > resolve > > > > > the > > > > > > > > old H2 > > > > > > > > > > > > > > evolution > > > > > > > > > > > > > > > > > thread > > > > > > > > > > > > > > > > > > [1] by ensuring it is used regularly on > the > > > > same > > > > > > code > > > > > > > > > > paths as > > > > > > > > > > > > > > > > > PostgreSQL. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Deprecating > > TransactionalMetaStoreManagerImpl > > > > for > > > > > > > > removal > > > > > > > > > > also > > > > > > > > > > > > > > sounds > > > > > > > > > > > > > > > > > > reasonable to me. Existing downstream > users > > > > > > > > > > > > > > > > > > of TransactionalMetaStoreManagerImpl will > > > have > > > > > > time to > > > > > > > > > > migrate, > > > > > > > > > > > > > or > > > > > > > > > > > > > > even > > > > > > > > > > > > > > > > > > embed that code (per ASF license) into > > local > > > > > > builds, > > > > > > > > > > during the > > > > > > > > > > > > > > > > > deprecation > > > > > > > > > > > > > > > > > > phase. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread/g1gg2w8hn9gvlmwrdh0x218whoh2wd39 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 11:24 AM > Alexandre > > > > Dutra > > > > > < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am writing to ask the community > whether > > > it > > > > is > > > > > > OK to > > > > > > > > > > deprecate > > > > > > > > > > > > > > > > > > > TreeMapMetaStore, as well as all the > > > > in-memory > > > > > > > > metastore > > > > > > > > > > > > > manager, > > > > > > > > > > > > > > > > > > > metastore manager factory, and > > persistence > > > > > types > > > > > > that > > > > > > > > > > rely > > > > > > > > > > > > > > solely on > > > > > > > > > > > > > > > > > > > TreeMapMetaStore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As we know, these components are > > test-grade > > > > > only, > > > > > > > > and not > > > > > > > > > > > > > > suitable for > > > > > > > > > > > > > > > > > > > production. They trigger a production > > > > readiness > > > > > > > > alert on > > > > > > > > > > > > > Polaris > > > > > > > > > > > > > > > > > > > startup. It's a considerable amount of > > code > > > > > that > > > > > > is > > > > > > > > > > virtually > > > > > > > > > > > > > > dead in > > > > > > > > > > > > > > > > > > > production. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's also confusing for developers. > E.g. > > > the > > > > > > > > > > "transactional" > > > > > > > > > > > > > > metastore > > > > > > > > > > > > > > > > > > > is not transactional in the JDBC sense > of > > > the > > > > > > term, > > > > > > > > and > > > > > > > > > > thus > > > > > > > > > > > > > not > > > > > > > > > > > > > > used > > > > > > > > > > > > > > > > > > > by JDBC persistence. It also has its > > > quirks: > > > > > some > > > > > > > > return > > > > > > > > > > > > > > statuses are > > > > > > > > > > > > > > > > > > > only returned by that manager. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, these components are used in > > > tests, > > > > > and > > > > > > I > > > > > > > > agree > > > > > > > > > > that > > > > > > > > > > > > > > it's > > > > > > > > > > > > > > > > > > > useful to have an in-memory version of > > the > > > > > > > > persistence > > > > > > > > > > layer > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > > tests. But we have today two > alternatives > > > > that > > > > > > are > > > > > > > > imho > > > > > > > > > > > > > superior > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > > tests in polaris-runtime-service: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - JDBC persistence with H2 backend. > There > > > are > > > > > > > > already a > > > > > > > > > > few > > > > > > > > > > > > > tests > > > > > > > > > > > > > > > > > > > using this setup. > > > > > > > > > > > > > > > > > > > - NoSQL persistence with InMemory > > backend. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Both alternatives test real > > > production-grade > > > > > > > > persistence > > > > > > > > > > code. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And finally, TreeMapMetaStore is > > currently > > > > the > > > > > > > > default > > > > > > > > > > runtime > > > > > > > > > > > > > > > > > > > persistence in application.properties; > > and > > > > the > > > > > > Helm > > > > > > > > > > chart also > > > > > > > > > > > > > > > > > > > advertises it as the default. These are > > not > > > > > sane > > > > > > > > > > defaults, > > > > > > > > > > > > > imho. > > > > > > > > > > > > > > It's > > > > > > > > > > > > > > > > > > > always tricky to provide a good default > > for > > > > > > > > datastores, > > > > > > > > > > but > > > > > > > > > > > > > > since JDBC > > > > > > > > > > > > > > > > > > > persistence is included by default in > the > > > > > server > > > > > > > > image, > > > > > > > > > > I think > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > including the H2 driver by default > could > > > give > > > > > us > > > > > > a > > > > > > > > saner > > > > > > > > > > > > > default > > > > > > > > > > > > > > while > > > > > > > > > > > > > > > > > > > keeping the out-of-the-box experience > > > intact > > > > > (the > > > > > > > > > > license is > > > > > > > > > > > > > > Category > > > > > > > > > > > > > > > > > > > A). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Concretely: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On the MetaStoreManagerFactory > hierarchy, > > > the > > > > > > > > following > > > > > > > > > > > > > > > > > > > implementations are completely > in-memory: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > InMemoryPolarisMetaStoreManagerFactory: > > > > could > > > > > > be > > > > > > > > > > removed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > InMemoryAtomicOperationMetaStoreManagerFactory: > > > > > > > > could > > > > > > > > > > be > > > > > > > > > > > > > > removed > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - LocalPolarisMetaStoreManagerFactory: > is > > > the > > > > > > base > > > > > > > > class > > > > > > > > > > of the > > > > > > > > > > > > > > two > > > > > > > > > > > > > > > > > > > above; imho it can be removed, but > since > > > it's > > > > > an > > > > > > > > abstract > > > > > > > > > > > > > class, > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > > > may have been extended outside Polaris. > > But > > > > > > neither > > > > > > > > JDBC > > > > > > > > > > nor > > > > > > > > > > > > > > NoSQL use > > > > > > > > > > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On the PolarisMetaStoreManager > hierarchy: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - TransactionalMetaStoreManagerImpl: is > > > only > > > > > > used by > > > > > > > > > > > > > > > > > > > LocalPolarisMetaStoreManagerFactory. > JDBC > > > and > > > > > > NoSQL > > > > > > > > do > > > > > > > > > > not use > > > > > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > Could be removed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - TransactionWorkspaceMetaStoreManager > > > > however > > > > > > is a > > > > > > > > > > different > > > > > > > > > > > > > > beast, > > > > > > > > > > > > > > > > > > > in spite of the similar name. It is in > > use > > > > > today > > > > > > on > > > > > > > > the > > > > > > > > > > commit > > > > > > > > > > > > > > path, > > > > > > > > > > > > > > > > > > > so should not be removed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On the BasePersistence hierarchy: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - TreeMapTransactionalPersistenceImpl > and > > > its > > > > > > > > > > TreeMapMetaStore > > > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > only used by > > > > > > InMemoryPolarisMetaStoreManagerFactory, > > > > > > > > and > > > > > > > > > > could > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > > > > removed; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - TransactionalPersistence and > > > > > > > > > > > > > AbstractTransactionalPersistence: > > > > > > > > > > > > > > these > > > > > > > > > > > > > > > > > > > are supertypes of > > > > > > TreeMapTransactionalPersistenceImpl > > > > > > > > > > and thus > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > > > used for in-memory. They imo can be > > > removed, > > > > > but > > > > > > they > > > > > > > > > > might > > > > > > > > > > > > > have > > > > > > > > > > > > > > been > > > > > > > > > > > > > > > > > > > extended or implemented outside > Polaris. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think it's important to keep Polaris > > code > > > > > tidy > > > > > > by > > > > > > > > > > removing > > > > > > > > > > > > > > unused, > > > > > > > > > > > > > > > > > > > unimplementable, or test-grade only > > > > components. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What are your thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
