Re: Postgresql implementation

+1 to keep the Guice suffix for guice modules

It indeed is explicit enough and now different from data definitions.

IMO this is good enough and a potential rename benefit do not necessarily outweight the cost of such a refactoring.

-- 

Best regards,

Benoit TELLIER

General manager of Linagora VIETNAM.
Product owner for Team-Mail product.
Chairman of the Apache James project.

Mail: [email protected]
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)


On Mar 19, 2025 9:39 AM, from Jean Helou <[email protected]>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 <[email protected]> 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: [email protected]
> Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
>
>
> On Mar 18, 2025 3:21 AM, from Tran Tung <[email protected]>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 <[email protected]> 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: [email protected]
> >> For additional commands, e-mail: [email protected]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>