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
wrote:
> Apologies for not getting back at this earlier. I somehow missed this email
> thread.
> To conclude the discussion we ended up doi
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 feedb
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 t
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 wrote:
>
> Good point about
So long as EclipseLink is not completely yanked from the repo I would
prefer to keep the tests running, even if it means the tests take longer to
run. The risk of a regression seems too great.
On Mon, May 5, 2025 at 3:18 PM Dmitri Bourlatchkov wrote:
> Good point about tests!
>
> However, I beli
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 Je
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" JDB
+1 (non-binding). Agreed with Dmitri that we should attempt to remove
EclipseLink post v1.0 release and mark it as deprecated in v1.0 itself.
-Adnan
> On May 2, 2025, at 4:03 PM, Dmitri Bourlatchkov
> wrote:
>
> Deprecating EclipseLink makes sense to me.
>
> It served well in the early days
Deprecating EclipseLink makes sense to me.
It served well in the early days of Apache Polaris, but at this stage the
new JDBC impl. outperforms it in terms of ease of use and concurrency, I
think.
I'd suggest marking the upcoming 1.0 release at the last release with
EclipseLink, unless we know of
+1, excellent work on the JDBC implementation!
On Fri, May 2, 2025 at 3:39 PM yun zou wrote:
> +1 (non-binding)
>
> On Fri, May 2, 2025 at 3:21 PM Yufei Gu wrote:
>
> > +1 on deprecating the EclipseLink backend.
> >
> > Yufei
> >
> >
> > On Fri, May 2, 2025 at 3:00 PM Prashant Singh
> > wrote:
+1 (non-binding)
On Fri, May 2, 2025 at 3:21 PM Yufei Gu wrote:
> +1 on deprecating the EclipseLink backend.
>
> Yufei
>
>
> On Fri, May 2, 2025 at 3:00 PM Prashant Singh
> wrote:
>
> > Hi all,
> >
> > I’d like to get your thoughts on deprecating EclipseLink and making JDBC
> > the default for
+1 on deprecating the EclipseLink backend.
Yufei
On Fri, May 2, 2025 at 3:00 PM Prashant Singh
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 tr
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) semant
13 matches
Mail list logo
