Hello again, I used some time building a migration tool that allows for an easy migration from JPA (backed by any database) to postgres for all the tables supported by data-api. You can review the corresponding pull request at https://github.com/apache/james-project/pull/2679
Doing so was a bit painful because of the choice of using `PostgresModule` to store the postgres table and indices definitions. The suffix `Module` conflicts with the suffix used for guice assembly leading to duplicate/ambiguous class name: `PostgresDropListsModule` vs `PostgresDropListsModule` or `PostgresMailRepositoryModule` for example. They can be disambiguated using the package name but its not trivial unless you are extremely familiar with the code. Can you tell from just the name which of `org.apache.james.mailrepository.postgres.PostgresMailRepositoryModule` or `org.apache.james.modules.data.PostgresMailRepositoryModule` is the Guice module from `james-server-postgres-common-guice` or the postgres module from `data-postgres` ? In a database context, a description of the database schema (table, indices, constraints etc) is usually referred to as DDL. What would you think of renaming `PostgresModule` to `PostgresDDL` and all the interfaces that expose from `PostgresXxxModule` to either `PostgresXxxDDL` or even to `XxxPostgresDDL` ? I am not sure if there is a specific rationale behind the current naming scheme so I prefer asking before investing any time in a rename. cheers Jean Le jeu. 13 mars 2025 à 14:07, Tran Tung <vtt...@linagora.com> a écrit : > Hello, > > The table structures are different. While some tables may share the same > basic structure, the team did not clone the JPA table schema when > developing for PostgreSQL. > > Because some feature was not supported by JPA (eg: JMAP) > But support with Postgres, so the JPA structure is not entirely suitable. > > For example, when enabling the Row-Level Security (RLS) feature, certain > Postgres tables require an additional `domain` column. > One other example: the team is using the `hstore` column type, which is > native to PostgreSQL. > > Therefore, a new database is necessary when starting with the > PostgreSQL-based application. > > Regarding migration, I know the IMAP sync tool for mailbox data, but no > tool yet to migrate all data from the old JPA to the new Postgres. > > Tung. > > On 3/13/25 7:05 PM, Jean Helou wrote: > > Hello everyone, > > > > I am looking into switching the scaling-pulsar-smtp from the JPA stack to > > the Postgresql stack. > > The scaling-pulsar-smtp assembly uses a SQL database to store > > - domains > > - users > > - recipient rewrite tables > > - mail repository url store > > > > I naively used the JPA implementation to connect to a postgresql db so I > > thought migrating would be easy enough : swith the implementation and > > restart the server > > Unfortunately it doesn't seem as easy as that : > > the JPA implementation generated tables in the configured schema with a > > `james_` prefix > > - domains => `james_domain` > > - mail repository url store => `james_mail_repos` > > - users => `james_user` > > - recipient rewrite tables => `james_recipient_rewrite` > > > > whereas the postgresql implementation expects different table names: > > - domains => `domains` > > - mail repository url store => `mail_repository_url` > > - users => `users` > > - recipient rewrite tables => `rrt` > > > > The name of the columns within each table are different too. > > the objectives for the new implementation state that it is destined to > > replace the jpa build but the migrating documentation only mentions > > migrating the mailbox contents not migrating all the data from data-api > ... > > sounds like this is not going to help adoption of the new implem > :grimacing: > > > > Do you happen to have a migration tool I missed to help with switching > > implementation ? > > > > Thanks > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
