Hi
Let's split the discussion in two parts. This thread is about
polaris-admin-tool DockerHub repo.
We have a consensus on option 3, so I will create a DockerHub repo for
admin-tool.
I will start a separate thread about nightly images.
Thanks everyone!
Regards
JB
On Fri, May 23, 2025 at 2:34 A
> This is a stricter requirement than we have for Iceberg tables. Are we
really going to enforce this? How will we do it efficiently? If not, let's
not put it in the spec.
The efficiency is a good point, if we are supporting
arbitrary nested namespaces,
the efficiency is definitely a concern. Mayb
My immediate reaction is that a configuration flag would be good enough for
us. Our setup prevents requests without a valid realm, so we're not subject
to the DDOS attack you mentioned, but we should address that in the default
realm context resolver as well. I can do some further investigation to
Personally, I’m unsure about what good a nightly Docker image build helps with.
If we’re backing up to the same Docker Hub repository, I think it could make
some sense as long as we manage the “latest” tag properly to only ever tag
releases since the proposed effort and maintenance overhead is l
> i meant no two tables under the same catalog can have the same location
This is a stricter requirement than we have for Iceberg tables. Are we
really going to enforce this? How will we do it efficiently? If not, let's
not put it in the spec.
> we do not have any update support
It would be tri
Hi Eric,
"No two tables globally can have a location overlap?"
-- let me correct that, i meant no two tables under the same catalog can
have the same location, which I think should be the right thing to do.
Otherwise, we might have a vended credential for a table that can be used
to access multipl
good point about Renovate!
On Wed, May 21, 2025 at 4:49 AM Robert Stupp wrote:
> How would tools like dependabot and Renovate distinguish work then?
>
> I think having separate `-unstable` repos is the safest way forward.
>
>
> On 20.05.25 19:10, Jean-Baptiste Onofré wrote:
> > Yes but we can us
Hi,
My proposal was centered around compile-time checks and targets mostly
developers and contributors. I am not questioning the usefulness of
runtime checks when these make sense.
Maybe an example is better than a thousand words. Let's imagine a
simple getOrDefault() method. Which version do you
Hi again,
Let's go back to the main concern: excessive memory required for metrics.
To move this discussion forward, would you all agree to introduce a
flag that activates the inclusion of realm IDs in the metrics?
It seems like this could be a good middle ground that addresses
everyone's needs.
Sounds good! Emojis voting is fun!
Yufei
On Thu, May 22, 2025 at 10:59 AM Russell Spitzer
wrote:
> Thanks to Scott and Dmitri for two nice design proposals
>
> https://github.com/apache/polaris/pull/1654
> https://github.com/apache/polaris/pull/1655
>
> Quoting what I wrote on 1654
>
> How abo
Thanks to Scott and Dmitri for two nice design proposals
https://github.com/apache/polaris/pull/1654
https://github.com/apache/polaris/pull/1655
Quoting what I wrote on 1654
How about we wait till 5/28 and link all alternatives in the parent issue
https://github.com/apache/polaris/issues/1653 an
My preference is for option 1 below.
On Thu, May 22, 2025 at 1:53 PM Alex Dutra
wrote:
> Hi,
>
> My proposal was centered around compile-time checks and targets mostly
> developers and contributors. I am not questioning the usefulness of
> runtime checks when these make sense.
>
> Maybe an examp
I have to disagree here.
In this thread, we discuss that *Polaris ships as a binary bundle, not a
pre-built Kubernetes chart.*
That bundle includes both the server and the admin tool for a reason: it
guarantees version compatibility and gives every user a friction-free way
to bootstrap a catalog,
Generally I agree on the proposal as well. Although I admit that I'm on
the fence there - neither pro nor con.
What I think would be quite useful is that the IDE respects the
non-null-default - not sure how good jspecify's @NullMarked/NullUnmarked
is being supported nowadays. There was another
Inlined.
On Thu, May 22, 2025 at 7:48 AM Dmitri Bourlatchkov
wrote:
> > Can we keep it simple for v1 [...]
>
> What is v1 in this context?
>
I meant as the first iteration, sorry for the confusion.
>
> Thanks,
> Dmitri.
>
> On Wed, May 21, 2025 at 8:42 PM Yufei Gu wrote:
>
> > Can we keep it s
I agree with what Alex proposed (quoted below).
Re: "assuming non-null by default". I believe this was intended in the
spirit of
code annotations, meaning that we need not use @Nonnull everywhere.
I do not think this was intended to mean that code does not have to check
that the value is not null
Hi everyone
Just a quick update: I’m preparing rc4. The vote will start tomorrow.
Thanks !
Regards
JB
I was going to make the same suggestion :) For deployments where the
complexity of an extra buffer doesn’t make sense, a blocking persistence
call will make things easier for the services owner. If read events are
added, a high throughput service will need the buffering probably. Though ,
I would b
Yun's proposal (quoted below) looks acceptable to me.
I see that Eric commented about multiple locations in his reply. Accounting
for multiple locations upfront would make sense to me too (I believe I
mentioned that earlier), but I'm also fine with a singular location for a
start, if it helps with
> Can we keep it simple for v1 [...]
What is v1 in this context?
Thanks,
Dmitri.
On Wed, May 21, 2025 at 8:42 PM Yufei Gu wrote:
> Can we keep it simple for v1, as one location field is enough for today’s
> use cases? And we can revisit multi-location support when there’s real
> demand.
>
> Th
Hi Yun,
[...] I think just having one page for "location" might be a little bit
overkill. Given that generic table API support is
a new catalog capabilities that Polaris added which is not IRC, I think it
might worth having a more general page to
describe the Polaris Generic Table support and desc
I haven’t thought of this in depth honestly - but I could see this being the
case.
-Adnan
> On May 21, 2025, at 4:39 PM, Eric Maynard wrote:
>
> -devlist
>
> If we design by interface properly, it should be relatively easy to offer
> both a disk buffering and an always-write implementation ri
22 matches
Mail list logo
