fivetran-arunsuri commented on issue #1875: URL: https://github.com/apache/polaris/issues/1875#issuecomment-2964443509
Hi @dimas-b, thank you for the quick response! I understand that the JDBC persistence implementation is a separate alternative and not a continuation of the EclipseLink-based one. That said, based on the latest production documentation and dev releases, it seems EclipseLink is being deprecated in favor of JDBC, particularly to address concurrency-related issues and to support scalable deployments more reliably. Given this direction, we see migration to JDBC as a necessary step to future-proof our system and avoid potential issues down the line. We’re currently evaluating the migration, and I’ll try out the [polaris-synchronizer](https://github.com/apache/polaris-tools/tree/main/polaris-synchronizer) tool as suggested. A few follow-up questions: - Are there any best practices or documented guidelines for using polaris-synchronizer specifically to migrate from EclipseLink to JDBC? - If polaris-synchronizer does not fully meet our use case or fails during migration, are there other recommended approaches or fallback options? - Are there known gaps, limitations, or caveats with the synchronizer tool that we should be aware of before planning the migration? - Does the Polaris community maintain or plan to maintain any tooling to help validate data consistency or integrity post-migration? - Also, out of curiosity—what were the key motivations for such significant changes in the DB schema between EclipseLink and JDBC-based persistence? Was this purely technical (e.g., performance/concurrency), or were there broader design goals behind it? Thanks again for the help and looking forward to your insights. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
