Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement]: Store different keys in different in-memory stores #1125

Open
1 task done
Har-Kuun opened this issue Jan 24, 2025 · 0 comments
Open
1 task done

[enhancement]: Store different keys in different in-memory stores #1125

Har-Kuun opened this issue Jan 24, 2025 · 0 comments
Labels
enhancement New feature or request

Comments

@Har-Kuun
Copy link

Which feature or improvement would you like to request?

I'd like to see this feature: It would be great to be possible to store different keys in different in-memory store.

Currently, only one in-memory store can be used. However, out of all the keys to be stored in the in-memory store, the two BAYES spam filter related keys need to be configured differently (e.g., in terms of persistence) than other keys. Therefore, it would be very handy if Stalwart supports the use of two in-memory stores at the same time, so that the two BAYES keys can be stored in a separate Redis instance or even another type of in-memory store.

Is your feature request related to a problem?

I'm having a problem with...

Code of Conduct

  • I agree to follow this project's Code of Conduct
@Har-Kuun Har-Kuun added the enhancement New feature or request label Jan 24, 2025
@Har-Kuun Har-Kuun changed the title 🚀: Store different keys in different in-memory stores Store different keys in different in-memory stores Jan 24, 2025
@Har-Kuun Har-Kuun changed the title Store different keys in different in-memory stores [enhancement]: Store different keys in different in-memory stores Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant