As commented in GH, I'm fine with closing https://github.com/apache/polaris/issues/777 now.
Cheers, Dmitri. On Thu, May 15, 2025 at 4:13 PM Prashant Singh <prashant.si...@snowflake.com.invalid> wrote: > Apologies for not getting back at this earlier. I somehow missed this email > thread. > To conclude the discussion we ended up doing the following : > [1] The service tests run with JDBC / in-memory persistence > [2] Admin tests (JDBC / EclipseLink persistence) > > Again thanks a ton everyone ! for your feedback and work ! > > Given that now we have achieved *Deprecate Eclipse Link and make Relational > JDBC as default* > via our docs and getting started etc reflect that very well ! > > I wanted to bring closing this issue as well : > https://github.com/apache/polaris/issues/777#top > As we no longer endorse Eclipse link which is where this originated from > and the current JDBC the default persistence > is very much permissive of the concurrent workload as demonstrated by : > https://lists.apache.org/thread/bz80l2fhtbfz3pqyfqp1c39ymmyqkc85 > > Please let me know you thoughts considering the same ^^^ > > > Best, > Prashant Singh > > > > > On Tue, May 6, 2025 at 8:59 AM Dmitri Bourlatchkov <di...@apache.org> > wrote: > > > 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 > > > > > > > > > > >
