Hello Matthieu. This looks interesting. Do you think you can provide a little pet exemple in the James context?
-- 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 11:08 PM, from Matthieu Baechler Hi, What about using Scala Doobie (tpolecat.github.io/doobie/) as it allows to write actual SQL with the comfort of a compiler and to bind results to case class quite easily? Cheers, -- Matthieu ------- Original Message ------- On Saturday, October 14th, 2023 at 16:48, Jean Helou <jhe...@apache.org> wrote: > > > 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) --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
