+1 to the proposal and unifying all the rather duplicated implementations.
> may have to bootstrap (new) realms multiple times without redeploying Polaris.
I'm not sure that this can work today, because the valid realms are
statically configured via 'polaris.realm-context.realms', so you'd
need t
Thanks for the summary, Alex!
+1 to all points.
Re: actionable items... maybe something like this?
1) Remove bootstrap from the main persistence call paths. Ideally, make a
new interface for it.
2) Control auto-bootstrap from top-level CDI constructs
like ServiceProducers
3) Use Quarkus config
+1 for the summary, agreed to simplify the approach to avoid partial schema
creation/update at this point.
Yufei
On Tue, Aug 5, 2025 at 12:39 AM Alexandre Dutra wrote:
> Hi all,
>
> Trying to summarize the opinions we've got so far:
>
> 1) On the server side:
>
> - Decouple schema setup and bo
Hi all,
Trying to summarize the opinions we've got so far:
1) On the server side:
- Decouple schema setup and bootstrap
- Schema setup should be off by default (opt-in)
- Schema setup should use "defaults"
- Schema setup is rather for tests or evaluation (=> production
readiness warning?)
2) On
> In practice though it is possible that different realms get bootstrapped
with different database schemas and I think we should try to make the
service resilient to situations like this
+1 on this. Each realm could have its own schema, or even different
Postgres server. A bit more context on it,
Agreed with Dmitri and Eric.
Since I worked on the PR, I thought I’d share a bit of context. I agree
that schema should not be a first-class concern, and that realm
bootstrapping should be the main concept users care about. I also agree
that a full bootstrap should remain the default behavior, but
+1 to everything Dmitri said, well put.
Ideally, I would say that "schema" ought not to be a first-class concept
within Polaris administration, just whether a realm has been bootstrapped
or not. In practice though it is possible that different realms get
bootstrapped with different database schema
Hi Alex,
Thanks for starting this thread! My opinions below.
> 1) Should schema setup be separate from realm bootstrapping?
I think it should be possible to execute the two actions separately. Yet, I
do not mind running them together by default.
> 2) Should the server perform schema setup at al
Hi all,
A nice recent contribution [1], still under review, proposes to create
a separate admin tool command for setting up the database schema.
Currently, schema setup is done as part of realm bootstrapping [2],
which can happen at server bootstrap, when running the tool's
bootstrap command, or
