+1 to rename the current classes both for Cassandra and PG to disambiguify this.
However DDL is an acronym that means little to me. Maybe *ProstgresDataDefinition VS *PostgresGuiceModule ? -- Best regards, Benoit TELLIER General manager of Linagora VIETNAM. Product owner for Team-Mail product. Chairman of the Apache James project. Mail: btell...@linagora.com Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) On Mar 18, 2025 3:21 AM, from Tran Tung <vtt...@linagora.com>When first starting, the naming of PostgresModule (which is actually where DDL is declared) was inspired by the naming convention used in Cassandra (CassandraModule) Later, I also realized that the term "Module" caused some readability and searchability issues (e.g., in the IDE, at least for me). +1, I think the naming "...DDL..." is more clear On 3/17/25 7:27 PM, Jean Helou wrote: > 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 > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
