I'd propose to convert all existing tests that use a Postgres database to JDBC.
Then (in the same PR) add dedicated integration tests for EclipseLink following the same approach that was used for JDBC ITs. This ensures that EclipseLink is covered by the normative Polaris "integration-tests". At the same time, all tests that are not normative from the Persistence perspective (perhaps they test something else... I did not check), use the new default persistence (JDBC). WDYT? Thanks, Dmitri. On Tue, May 6, 2025 at 2:48 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi > > My point is that we should have tests for both EclipseLink and JDBC > (parameterized). > I think it's acceptable to have "longer tests", just to be sure > EclipseLink still works fine (waiting to remove it). > > Regards > JB > > On Tue, May 6, 2025 at 12:17 AM Dmitri Bourlatchkov <di...@apache.org> > wrote: > > > > Good point about tests! > > > > However, I believe it still makes sense to transfer the main body of > tests > > using a "real database" to JDBC. It should be possible to run one > > Integration test on EclipseLink to make sure it works and still not > > overload CI. > > > > Cheers, > > Dmitri. > > > > > > On Mon, May 5, 2025 at 1:26 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > > Hi > > > > > > I already commented on the PR and forgot to reply here :) > > > > > > Yes agree to deprecate eclipselink it makes sense to me and promote > > > "JDBC" instead. > > > > > > That said, as said in the PR, I think we should keep the eclipselink > > > test still (even if deprecated): deprecation gives time for users to > > > "move to" JDBC but they can still use eclipselink, so it makes sense > > > to test it to be sure it works and there's no regression here. > > > > > > Just my $0.01 :) > > > > > > Regards > > > JB > > > > > > On Fri, May 2, 2025 at 11:59 PM Prashant Singh > > > <prashant.si...@snowflake.com.invalid> wrote: > > > > > > > > Hi all, > > > > > > > > I’d like to get your thoughts on deprecating EclipseLink and making > JDBC > > > > the default for our persistence layer. > > > > > > > > Our current EclipseLink setup mandates execution within a > transaction, > > > > which has introduced several issues — notably, an improper > implementation > > > > of CAS (compare-and-swap) semantics. To address these shortcomings, > > > Apache > > > > Polaris underwent a major refactor to decouple persistence interfaces > > > from > > > > strict transaction dependencies and to ensure actual CAS enforcement. > > > > > > > > As part of this effort, we introduced a new JDBC backend with a > simpler > > > and > > > > more performant schema, directly addressing the limitations of the > > > existing > > > > EclipseLink schema. > > > > > > > > We’ve observed significant improvements compared to the EclipseLink > > > > implementation. Notably, issues such as Polaris failing under minimal > > > > concurrency (e.g., with just 5 users) have been resolved: > > > > > https://github.com/apache/polaris/issues/1123#issuecomment-2756133924 > > > > > > > > Given these improvements, I propose we: > > > > > > > > - > > > > > > > > Deprecate EclipseLink > > > > - > > > > > > > > Make relational JDBC the default persistence implementation > > > > > > > > PR to support this change: > > > > [1] https://github.com/apache/polaris/pull/1515 > > > > > > > > Would love to hear your feedback on this. > > > > > > > > Best regards, > > > > Prashant > > > >
