Hello, I'm moving fast on this (too fast maybe and not letting every interested party express their thoughts, hopefully I'm not vexing anyone) As you probably saw I did the rename for PG from module to DataDefinition and am executing the rename for cassandra to DataDefinition.
I am not completely sure about the move from Module to GuiceModule : - there are a *lot* of guice modules (248 import statements for AbstractModule) - the guice modules mostly inherit from AbstractModule which is a guice type I don't really have a rationale but intuitively I feel that the Module suffix goes well with `AbstractModule. from what I could see all of the guice modules are under packages that are prefixed with `org.apache.james.modules` I think if there is a rename to do its to rename the packages to either `org.apache.james.guice` or `org.apache.james.guice.modules` These packages have also been released for a longer time and I think have a stronger chance of being pulled in custom assemblies (whereas the data definition modules are less likely to be pulled but it is still a breaking change) Since I'm not completely clear on what is the correct course of action myself, I do not plan to rename the guice modules for now. Jean Le mar. 18 mars 2025 à 11:35, Benoit TELLIER <btell...@linagora.com> a écrit : > +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 > > >
