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

Reply via email to