Hello Jean, Thanks for the suggestion!
So far, we started playing with R2DBC ( https://r2dbc.io/ ), and wrote a simple mapper for it: https://github.com/vttranlina/james-project/commits/postgres_lab We also have the plan to investigate Jooq and do the same kind of proof of concept with it. For now my opinion tends to lean on the fact that R2DBC is low level but does the job. Let's see if a jooq POC can make this opinion change. (DSL could be nice!) -- 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 Oct 14, 2023 9:48 PM, from Jean Helou Hello, I have been following the discussion on pg mailbox but every jpa mention makes me think of how bad I found the developer experience with open jpa when playing with scaling-smtp. (having to set the agent manually for tests in the ide is a pain. having to list the classes to instrument isn't much better and we had quite a few issues when moving scaling-smtp away from Cassandra and to PgSQL) So I'm forking the initial discussion to ask if there would be interest in migrating away from openjpa ? at least for new features. I have basically come to dislike most automatic ORMs but pure jdbc is very low level. I thus tend to favor wrappers that make my life easier without trying to hide the SQL. My current favorite wrapper is jooq ( jooq.org/). I am not sure if it would be an acceptable choice for James. While there is an open source version which uses apache 2, access to proprietary databases relies on proprietary code with a paying license. Apart from this I'm sure jooq would be nice especially if we are going for a PG only solution. Jooq DSL mirrors SQL quite closely to provide typesafety. it still allows writing SQL explicitly if the DSL is not enough. It returns a resultset in a thin wrapper that can be generated from the DDL to allow typed access to the result rowsm items. This then allows using a user provided mapper to build applicative objects. I tried searching the archives of the mailing list for references to jooq and found nothing but I may have missed things. The downside of migrating to jooq is that I'm not sure how easy it is to swap db backend with it and support for Oracle/DB2/commercial databases would require to buy a license. As I said I don´t know how much of a deal breaker that is.... jean Le ven. 6 oct. 2023 à 23:49, Benoit TELLIER <btell...@linagora.com> a écrit : > Hey there! > > The goal: deliver James "stateless email server" concept to smaller > deployments than those addressable with the Distributed server. > > Why Postgres? Rock solid. And more options than other SQL stores (see > below) > > The requirements would be: > - Leverage the blobStore for binary storage (email bodies + > attachements). Those big binaries are not meant to be stored into SQL rows > - blaming you, JPA! > - Bring choice on blob store : PGSQL native solution ( > postgresql.org/docs/7.4/jdbc-binary-data.html ) for small > deployments OR S3 > - Bring choice on search: PGSQL native solution ( > postgresql.org/docs/current/textsearch.html ) for small > deployments OR OpenSearch > - Bring choice on PubSub: PGSQL native solution ( > postgresql.org/docs/current/plpgsql-trigger.html ) OR > RabbitMQ > - Enforce strict tenant isolation: domain A won't access domain B data > even if we screw up James access control layer. This can be done with Row > security postgresql.org/docs/current/ddl-rowsecurity.html . > - Be reactive. This can be achieved by using a reactive firendly driver > like r2dbc... > - Ensure that we can easily run on some largely scaling postgres... > CitusData ? > > An other outcome might be to drop JPA implementation, ideally... (we > provide something similar but waaaay better) > > Ideally I would like to deliver this before september 2024... > > Thoughts? > Would this be something interesting people in here? > Would some people be interested contributing to this effort? > Would some people desire sponsoring this effort? > > If this is non consensual, I can also contribute this into > github.com/linagora/tmail-backend/ without annoying people in > here... > > > > -- > > 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) > > > > >
