-
Notifications
You must be signed in to change notification settings - Fork 805
Multi db #3783
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
base: main
Are you sure you want to change the base?
Multi db #3783
Conversation
fd9072d to
febdf01
Compare
|
This has also been discussed in #42 #330 #2299 #3050 #3051 and likely others. Speaking as a longtime user and fellow new contributor: I don't want this feature. Or any other variation. Miniflux's opinionated commitment to Postgres is a strength, keeping complexity and dependencies down. Support for multiple databases will only lead to incompatibilities and further maintenance burden. The migrations changes alone terrify me. Feature parity between databases is also just not there, especially for SQLite. Miniflux already depends on several Postgres-specific features. These would either have to be replicated and abstracted, moved to Go, or entirely scrapped. |
|
apparently maintainer is not fully against this as they wouldnt keep #1925 open and link it the differences between postgres and cockroachdb are minimal - only one function for full-text search is missing in cockroachdb that miniflux uses the stuff miniflux uses that is postgres-specific is minimal and mostly related to full-text search which can be implemented with a plain title search in sqlite as far as dependencies go im new to go but as far as i know its one extra driver - if thats too much to ask fine ill close and keep maintaining a fork that only supports cockroachdb and yes this adds complexity but this is the number one most reacted to issue on this repository |
|
I'm not @fguillot so I won't pretend to make decisions for the project. Just linking what was previously said.
FWIW I've been working on some changes to FTS and tagging that would increase incompatibility.
I don't see a change to |
what if you don't and ping me to port it to sqlite/cockroachdb? there really isn't that much thats postgres-specific - most stuff in this repo is basic CRUD SQL
correct - no extra deps needed
im sorry but not sure i follow why this is a problem sqlite is a very well established project is the binary size a problem? this is why i wanted to hear from the maintainer on what they mean by minimalism because it felt odd to me that they would keep that issue open for so long and not want this |
05b4d33 to
fe6c000
Compare
fe6c000 to
e9b8279
Compare
Have you followed these guidelines?
Hello :)
This is my first contribution and while i read the guidelines there I'm creating this draft PR just to get a better idea on what you consider minimalist here.
This is an initial effort to support multiple databases and for now cockroachdb support is added just so we can come to a consensus on what is the right approach here.
The final goal here is to close the popular #1925 (sqlite support) issue.
I also added a flake and helix configuration because that's what i use for development. I saw you use devcontainers but I am not at all familiar with them.
Please take note that I have not tested this specific code at all. What I have tested, however, is the cockroachdb patchset. Since creating that, I made some adjustments here to support multiple databases and then ported over that patchset so it doesn't interfere with the existing code (hopefully).