[
https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876212#comment-17876212
]
Wojtek commented on JAMES-2586:
-------------------------------
> (technically JIRA ends up on the JIRA)
??
You mean on the mailinglist?
>> [http://jdbi.org/] considered instead of jOOQ?
> No
> But in the choice reactive support was important.
> Does jdbi supports it?
Seems it doesn't:
[https://github.com/jdbi/jdbi/issues/1454#issuecomment-1314602688] (one of the
reason seems to be too much dependency on Reactor…)
Though I brought it up as there was a mention of licence compatibility (which
seems irrelevant if the focus is only on Postgres…) and Jibi is another Apache
project.
>> Another point - if such tool is used then it should still be possible to be
>> independent from the database (sanse blob-store)?
> I do not understand. Can you please clarify?
Considering that index-serach is not done against Postgrest directly (but uses
OpenSearch or now maybe Lucene) and that blob-store would be done "Bring choice
on blob store : PGSQL native solution for small deployments OR S3" (por.
[https://lists.apache.org/thread/lo04f7v2pmxkxc2n4wlcgrb90dn8br4t)]
So that leaves basically "storing mails as binary directly" (but with jOOQ this
could be extended to other databases still with BINARY/VARBINARY?) and events
(pubsub native ones or RabbitMQ... but one can use ActiveMQ build-in as well;
not sure if used either way given that native-PG-search was dropped).
Thus, considering all the above - dropping JPA in favour of jOOQ doesn't have
to mean being Postgres-only but could support other databases that jOOQ
supports? ;-)
To be honest I'm trying to grasp the current scope of the task and the extent
of which it would make it Postgres-only :)
> Implement a Postgres-specific backend
> -------------------------------------
>
> Key: JAMES-2586
> URL: https://issues.apache.org/jira/browse/JAMES-2586
> Project: James Server
> Issue Type: New Feature
> Reporter: Matthieu Baechler
> Priority: Major
> Time Spent: 235.5h
> Remaining Estimate: 0h
>
> James has a JPA implementation of most interfaces that allows to deploy it on
> top of some popular RDBMS.
> However, while useful for some kind of applications, ORM are usually a bad
> fit for applications requiring high performance like a mail server.
> As an abstraction, it also prevents from using advanced features of a given
> RDBMS.
> For most usages, James would probably run great on top of Postgres, given
> that we use advanced features to implement search, for example.
> A good strategy would be to implement all interfaces implemented by JPA with
> a modern Postgres driver.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
