Hi Mike
Fair point about "admin" endpoints. In terms of "transition", I
propose to add a filter/redirect to be backward compatible and give
time to admin to move to the new endpoints.
I will create an issue and tackle that.
Thanks !
Regards
JB
On Wed, Jan 15, 2025 at 4:08 AM Michael Collado wro
I also noticed Yufei's comment re: the health checker endpoint, which is
now gone. Is there an issue to address that as well? I think we ought to
treat the admin endpoints (/healthcheck and /metrics) just as we would
treat the management or catalog APIs - that is to say, we wouldn't simply
remove o
Personally, I find the current in-memory store invaluable for debugging.
It's really easy to crack open the tree map and see what entities exist
when tracing down a problem. I'd hate for that to go away and rely on H2 or
sqllite or something.
I also haven't yet heard any user championing EclipseLi
Hi JB,
Thanks for the review. As we discussed, engines can still use table
properties if that's preferred.
In the case that a table is visited by multiple engines, these optional
properties become critical, allowing admins or SREs to specify specialized
“recipes” for table maintenance engines.
Y
The “blanket” is not a blanket: it’s just the note about gradle.
I do read it as a blanket statement because it is not clearly associated
with the next lines about gradle and refers to “various third-party
components”. Here’s the text:
This product bundles various third-party components also unde
Hey JB, I just sent a reply to the list with additional details. I don't
think that this release applies license policy correctly even in the other
files, so my vote is still -1.
On Tue, Jan 14, 2025 at 11:05 AM Jean-Baptiste Onofré
wrote:
> Hi Ryan
>
> As you can see in my previous email, I tot
Hi Ryan
As you can see in my previous email, I totally agree with you about the
issues on the LICENSE_BINARY_DIST.
As this release only includes source distribution (no jar files, no binary
packages), and I checked LICENSE/NOTICE for this distribution (see my vote
email for details), I think we ar
+1 (non-binding). The source distro looks good to me. There is a lot of
work to do before we're ready for the binary distribution, but I don't
think that should block this first source distro.
Mike
On Tue, Jan 14, 2025 at 1:19 AM Jean-Baptiste Onofré
wrote:
> +1 (binding)
>
> As this release in
I think providing direct JDBC as an alternative to EclipseLink is
potentially a good idea. I am concerned about the prospect of totally
removing the TreeMap implementation and dropping down to only EclipseLink.
Michael remarked the other day that you often need >2 implementations
before an abstract
I thought we discussed experimenting directly using JDBC (without
EclipseLink) and we will decide what's the best option.
On Tue, Jan 14, 2025 at 4:53 PM Alex Dutra
wrote:
>
> Hi all,
>
> I think Dmitri's suggestion makes sense as a short-term solution. Removing
> EclipseLink is a much bigger tas
Removing the direct in-memory MetaStore should help with refactoring the
"persistent" impl. code later, I hope mainly because it reduces the
amount of work to be done in supporting alternatives.
On Tue, Jan 14, 2025 at 10:55 AM Alex Dutra
wrote:
> Hi all,
>
> I think Dmitri's suggestion make
As a "midterms" solution, I agree.
Regards
JB
On Tue, Jan 14, 2025 at 4:53 PM Alex Dutra
wrote:
>
> Hi all,
>
> I think Dmitri's suggestion makes sense as a short-term solution. Removing
> EclipseLink is a much bigger task, and I don't think we'll have time to do
> that before the 1.0.0 release.
Hi all,
I think Dmitri's suggestion makes sense as a short-term solution. Removing
EclipseLink is a much bigger task, and I don't think we'll have time to do
that before the 1.0.0 release. Imho the 1.0.0 release will ship with
Quarkus + EclipseLink.
Thanks,
Alex
On Tue, Jan 14, 2025 at 4:25 PM J
Hi Dmitri
That's a fair question. I agree about H2, but I'm not sure about
EclipseLink, especially now that we are powered by Quarkus.
Why not directly using JDBC (without EclipseLink) ?
Quarkus Panache is not really an option for now due to license issue
(Hibernate ORM).
Regards
JB
On Tue, Jan
Hi All,
Given that it is possible to run EclipseLink with H2 in memory, is there
value in keeping a separate in-memory MetaStore implementation?
My main concern is that the plain in-memory MetaStore is significantly
different from the EclipseLink metastore and might deviate in behaviour.
With tha
Hi all,
As mentioned already in another email earlier today, we still have a few
PRs to merge to fully achieve the transition to Quarkus.
The first one is the Docker PR: https://github.com/apache/polaris/pull/610
Since it's an important topic, I would like to summarize the most important
changes
Hi all,
The Quarkus PR has finally been merged today! I would like to thank all of
you who spend time reviewing and testing this.
A few follow up PRs were merged too. Please take some time to walk through
the new code; JB, Robert, Dmitri and I are available to answer any
questions and also to hel
+1 (binding)
As this release includes only source distribution, it's fine because:
- hash and signature are OK
- incubating is in the name/version
- DISCLAIMER_WIP is there
- LICENSE is OK, including note about Apache licensed third-party
components (e.g. gradle). We can optionally mention
Polaris
18 matches
Mail list logo
