[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ 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
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[
https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877348#comment-17877348
]
Wojtek commented on JAMES-2586:
---
> Of course have multiple implementations in parallel brings maintenance
> overhead. Not to mention the JPA implementation lags behind in terms of
> features (eg JMAP but not only - using a S3 compatible store for instance
> could be a thing) and I {*}wouldn't personally be confident seeing it used in
> 20+ mailbox deployment{*}.
Touching on the previous point - why? Was there any performance issues
previously and/or performance comparison with new implementation?
Disclaimer point instead of outright deprecations seems sensible though :)
> JPA schema was generated by an ORM and is mostly "accidental". An full data
> migration (likely using tools like imapsync) would be needed.
Thank you for clarification. So it doesn't matter all that much if someone uses
MySQL or PostgreSQL - after all a migration will be needed.
Nevertheless - I still think that it _could_ be possible to make the new
implementation more independent of the underlying database (thus making it good
replacement for [supposedly] non-performant JPA) without sacrificing possible
performance gains of dropping JPA?
> 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
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877663#comment-17877663 ] Wojtek commented on JAMES-2586: --- > Contribution welcomed. Understood, though this hangs a lot on the James' team stance and "only postgres". I guess that if it could be shown that something more universal offers ~comparable performance then such submission would be acceptable? I remember that work but this was less about performance but more about the memory leak. Nevertheless it gives some insight. Do you have any recommnded tool to load-test James so it would be possible to easily have reproducible tests? (JMeter)? > 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
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138472#comment-17138472 ] Ioan Eugen Stan commented on JAMES-2586: Hi [~matthieu], I fully believe and support what you mentioned. Are you planning to work on this? Having that implementation is going to also require maintenance. If you or nobody else is going to work on this, let's please close the issue. > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138487#comment-17138487 ] Matthieu Baechler commented on JAMES-2586: -- I disagree with you about that: issues also describe things that we could do. It can be picked-up be somebody wanting to contribute for example or it can be a good reason for a company to fund the project knowing that some people could do that implementation. If you want to close every ticket that has not received any contribution for some times, I don't understand what you expect from this issue tracker. > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[
https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138583#comment-17138583
]
Ioan Eugen Stan commented on JAMES-2586:
Hi,
Thanks for getting back.
We have different opinions and I think that is ok.
I do hope we reach a consensus helpful for the whole project.
I'll explain my opinions and reasons why I think closing issues.
You might share some and disagree with some of them.
The issue tracker is meant as a way to record and track issues that people
have.
It's focused on what needs to be done now (where now is loosely used here).
I'll start with some generic reasons.
Having a lot of open issues does not help with the focusing part IMO.
It's hard (for me) to tell what should we focus on and what we should not.
Why should we keep issues open for more than 1-10+ years if no one is going to
work on them.
The issues can always be re-opened if necessary so why is it neccesary for us
to see them every time we use JIRA ?
It's my opinion that if things are important enough they get fixed.
If they are not important enough, they are left behind.
I do believe that keeping things tidy and clean improves the overall "healthy
and good" feel of the project, just like a clean room has a strong impression
on us.
Who wants to live in a unkempt dirty room?
Getting back to this particular issue.
I had the same idea you had since I love PostgreSQL (my default DB) and I know
some things are not implemented very good in JPA.
However I pondered a bit on decided against it was just wishful thinking.
I do believe this is a good idea to explore but unless someone takes the time
to work on it is a nice wish.
We should not have to see it every time we open JIRA and spend a few moments
asking ourselves: What is this all bout? Is this relevant? Is someone working
on this, will it be part of the release ?
If you want to keep the issue open please do.
It's not a thing we should argue over.
However I do hope you see the value in what I am proposing and what others have
implemented for similar reasons to the ones I shared above.
Bellow is a link and a comment from another project that has implemented
automated "Issue rotting".
https://github.com/ansible/ansibullbot/issues/1011
{noformat}
We discussed this at AnsibleFest Atlanta during the Community Summit. The
in-room consensus was to use a model similar to K8s' bot, where:
After 30d with no activity, open feature request is marked 'stale'
After 90d with no activity, open feature request is closed
{noformat}
> 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
>
> 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.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138603#comment-17138603 ] Matthieu Baechler commented on JAMES-2586: -- I do understand your arguments. What I also understand is that you actually use JIRA in a way I'm not. JIRA is designed for issue tracking, we describe problems, limitations, bugs but also improvements and ideas. It's not a project management tool for me: I mean, I'm happy to search things in it as a knowledge base but I don't intend to empty the list of non-closed ticket as it's just unreachable on such a project: there will always be more things to do than contributors can handle. It can be used as a project management tool when you start to assign tickets to a milestone and then you don't have to deal with how much open tickets there are in the system because you will filter on milestones. You can also use something external to JIRA to handle project management (for example github project). On the positive side of keeping things open: it allows to communicate intents. Other people can comment, contribute some related doc or code, etc. Would you search for closed issue for improvements or new features? > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138745#comment-17138745 ] Ioan Eugen Stan commented on JAMES-2586: Thanks. It's a bit clear for me from where the difference in perspective comes from. For managing the project we have a few tools at our disposal: JIRA for issue tracking, mailing list and gitter for discussion, the documentation files, the James website. Each tool has a purpose and sure there is overlap between them. I don't believe I hold the absolute truth about how tools should be used and which tool is used for what. I would like to reach a common understanding so we can all work together to produce good software and enjoy life. Please keep this in mind while you read the next pieces of text. As you correctly pointed out, I do consider JIRA for issue tracking and doing the project management part. We also have github and this creates duplication and we should discuss this in another thread. I think ideas should be discussed on the mailing list. The mailing list is indexed and appears in google results. Mailing list serve this purpose - discuss ideas, offer support: https://www.apache.org/foundation/mailinglists.html . If the idea has merit and people are willing to work on it, we can use JIRA to track and coordinate. I don't think JIRA is a good place for ideas since it interferes with the project management part. For example in kubernetes they have thousands of issues. They mark them stale and rotten because otherwise they would be overwhelmed. We don't have thousands of open issues and I don't want to reach that number. Low number of issues means it's easy for us to focus on those things and get them done. It's easy for someone who joins the community to identity the current issues and work on them. > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139011#comment-17139011 ] Benoit Tellier commented on JAMES-2586: --- > It's easy for someone who joins the community to identity the current issues > and work on them. At some point we introduced a @newbie label for this purpose. BTW I agree that a project with loads of open, outdated tickets looks unfriendly. > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139010#comment-17139010 ] Benoit Tellier commented on JAMES-2586: --- > We also have github and this creates duplication and we should discuss this > in another thread. In my opinion github should be limited to reviewing code. So I see little overlap. > I think ideas should be discussed on the mailing list. +1 I just want to add nuance. Browsing mailing list to retrieve things could be harder than JIRA tickets where you can link things together, rely on components, label things, etc... Maybe the right thing to do is leverage our tooling to allow both of your goals to be achievable. Maybe we could introduce a 'label' for long term propositions that could easily be filtered in & out ? > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17139945#comment-17139945 ] Matthieu Baechler commented on JAMES-2586: -- I don't have opinion about whether we should use JIRA or a mailing list to discuss ideas: it looks like both work currently. What do we gain at restricting usage to only one of them? And then, who will enforce the choice? Eugen, you said using JIRA to keep ideas and/or mid/long term goals interferes with the project management part: my argument is that filtering on milestone solves that issue and you didn't answered, as far as I understand. Of course I want to reach a global agreement and I don't care that things stay as they are or fit my habits. Community comes first. Thank your for bringing this debate. > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2586) Implement a Postgres-specific backend
[ https://issues.apache.org/jira/browse/JAMES-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140474#comment-17140474 ] Ioan Eugen Stan commented on JAMES-2586: We can decide how we use the tools and *document* those decisions. We can do that as part of a future community effort (via a community call). That way we as a community decide and we enforce them by pointing things out. It should be more of a soft enforcement than a hard one: please do that instead of this, because it's more useful for us to maintain the project. What I would like to get out of is a clear process for how we encourage contributions. This is intended to make our lives simpler when we manage the future of Apache James: we have a simple process, we expect people to behave and we have some expectations of how things will unfold. > 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 > > 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.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
