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
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
