Re: Polaris persistence refactor POC

Yes I know (remember I proposed to use DAO so I know what it is :)). If it’s clear for everyone, ok for DAO (just wanted to be sure that it’s clear for the implementers). So ok to have CatalogDao for operations and CatalogRecord for carriage data (for instance). Thanks Regards JB Le mar. 18 févr

Re: Polaris persistence refactor POC

Hi JB, DAO is often defined as an interface, used exactly for operations. Why do we need another name for that? See the examples here , it can be with JPA or non-JPA. In our case, it has to be compatible with non-JPA implementation. inter

[VOTE] Release Apache Polaris 0.9.0-incubating (rc6)

Hi folks, After the vote on the incubator general mailing list, we fixed the DISCLAIMER content and cleaned up the NOTICE file. This is the vote for Apache Polaris 0.9.0-incubating rc6. * This corresponds to the tag: apache-polaris-0.9.0-incubating-rc6 * https://github.com/apache/polaris/tree/ap

Preparing 0.9.0 rc6

Hi folks We merged the fix about DISCLAIMER and NOTICE. I will proceed with 0.9.0 rc6 vote. Stay tuned ! Thanks Regards JB

Re: Polaris persistence refactor POC

Hi Yufei I agree with you. My only concern with CatalogDAO and NamespaceDAO in the PoC is that it could not be obvious for implementer. Being very abstract force us to clearly decouple service and persistence. One interface or multiple interfaces is totally fine for me (for the storage operations)

Re: Polaris persistence refactor POC

Hi JB, The Java objects you mentioned should either belong to the service/business layer or be unnecessary. Apart from the business entities in Polaris, each backend will maintain its own set of persistence-layer entities. The backend implementations (whether Postgres, FDB, or MongoDB) will be res

Re: Apache Polaris 1.0 Release – Next Milestones and Release Manager Volunteer

Yeah, we should remove the “bug” label from anything that’s not a bug. Improving code quality and improving code and api abstractions are good goals, but they’re not bug fixes. Mike On Mon, Feb 17, 2025 at 8:12 AM Eric Maynard wrote: > There are still many issues labelled as "bug" that are not

Re: Apache Polaris 1.0 Release – Next Milestones and Release Manager Volunteer

There are still many issues labelled as "bug" that are not bugs but feature requests or requests for some refactoring, e.g. (1 , 2 , 3 ). I do not think that we

Heads up: Contributing guidelines / Good Practices

Hi guys, just a heads-up that our contributing guidelines has a "Good Practices" [1] section. * Change of public interface (or more generally speaking Polaris extension point) should be discussed and approved on the dev mailing list. The discussion on the dev mailing list should happen

Re: Polaris persistence refactor POC

On 17.02.25 18:36, Yufei Gu wrote: Hi JB, The Java objects you mentioned should either belong to the service/business layer or be unnecessary. Apart from the business entities in Polaris, each backend will maintain its own set of persistence-layer entities. The backend implementations (whether

Re: Polaris persistence refactor POC

The purpose of code generation from the openapi spec is to ensure that api changes are made spec-first. There is no opportunity to forget to change the spec and there’s no worry about the code and the spec deviating (at least, the endpoints don’t differ). The generated code, if “not great” is extre

Re: Polaris persistence refactor POC

Everything you have to code manually requires explicit tests. Immutables is a very mature library that has exceptionally good test coverage that prevents a ton of accidental coding mistakes. We've been using it for many many years in multiple projects and literally never produced wrong code.

Re: Polaris persistence refactor POC

Generating code based on the spec is completely different than generating code based on the annotations introduced by Immutables. More importantly, we shouldn’t allow a discussion about pushing the project forward to devolve into a debate around some third-party library that’s not necessary to the

Re: Apache Polaris 1.0 Release – Next Milestones and Release Manager Volunteer

The label "bug" is good enough for any bugs. I was also thinking of other non-bug requirements, for example, the persistence refactor. Yufei On Mon, Feb 17, 2025 at 8:38 AM Robert Stupp wrote: > > On 12.02.25 21:03, Yufei Gu wrote: > > Thanks, Robert, for chiming in. Production readiness is ind

Re: Polaris persistence refactor POC

I prefer native Java constructs over third party libraries and compiler plugins, whenever possible. I’m a fan of Java records. Mike On Mon, Feb 17, 2025 at 6:55 AM Jean-Baptiste Onofré wrote: > Hi Robert, > > Yes, my intention about Java records (e.g. > https://openjdk.org/jeps/395) is to lever

Re: Apache Polaris 1.0 Release – Next Milestones and Release Manager Volunteer

On 12.02.25 21:03, Yufei Gu wrote: Thanks, Robert, for chiming in. Production readiness is indeed a crucial point, and I'm open to any proposals that can help us achieve it. I also believe this is the right time to identify any blockers. To help with tracking, I'd suggest we add a dedicated lab

Re: Polaris persistence refactor POC

Hi Robert, Yes, my intention about Java records (e.g. https://openjdk.org/jeps/395) is to leverage: - Devise an object-oriented construct that expresses a simple aggregation of values. - Focus on modeling immutable data rather than extensible behavior. - Automatically implement data-driven methods

Re: Polaris persistence refactor POC

Agree with JB, except I think "immutables" serves the need much better. Java records are okay, but do not ensure that all fields are immutable - especially collections. The other pro of immutables is that there are proper, descriptive builders - hence no need to constructors with a gazillion pa

Re: [Polaris Persistence Refactoring Meeting] Feb. 13, 2025 record

Great idea about proposals and corresponding records. Let me do that ! Regards JB Le lun. 17 févr. 2025 à 12:34, Robert Stupp a écrit : > > On 17.02.25 11:45, Jean-Baptiste Onofré wrote: > > Hi folks, > > > > Here's the record for the meeting where we discussed about the Polaris > > persistenc

Re: [Polaris Persistence Refactoring Meeting] Feb. 13, 2025 record

On 17.02.25 11:45, Jean-Baptiste Onofré wrote: Hi folks, Here's the record for the meeting where we discussed about the Polaris persistence refactoring: https://drive.google.com/file/d/1CxwZvnk8ZXsg2EpxGoj-5Hj_acZAxuGe/view?usp=sharing +1 I also propose to have a section on the website (

[Polaris Persistence Refactoring Meeting] Feb. 13, 2025 record

Hi folks, Here's the record for the meeting where we discussed about the Polaris persistence refactoring: https://drive.google.com/file/d/1CxwZvnk8ZXsg2EpxGoj-5Hj_acZAxuGe/view?usp=sharing I also propose to have a section on the website (https://polaris.apache.org/community/meetings/) for specif

Re: Polaris persistence refactor POC

Hi Yufei I left comments in the PR. Thanks for that. That's an interesting approach but slightly different to what I had in mind. My proposal was: 1. The DAOs are Java records clearly descriptive, without "storage operations". For instance, we can imagine: public record CatalogDao(String id, S

Polaris persistence refactor POC

Hi Folks: Here is a POC for persistence layer refactor. Please check it out and let me know what you think. Please note this is a POC, we still need a lot of effort to complete the refactor. PR: https://github.com/apache/polaris/pull/1011. Design doc: https://docs.google.com/document/d/1Vuhw5b9-6