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
Suggestions #17
Comments
Will consider this. The re-usable and extensible parts are already packages and it's just HTTP handlers in the main package.
I took this route initially. Tried gorm, xorm etc., but dealing with ORMs was limiting and painful. Most of listmonk's queries use CTEs extensively and they'd have to be hand-written anyway. Also, listmonk relies heavily on Postgres features such as JSON blob and indexes. I don't think the complexity of supporting multiple DB backends is beneficial. The table structures are really simple, so it's straight forward to integrate with external CRMs by directly manipulating table data or using APIs. Thanks |
I agree. I've worked on similar software and the queries really need to be written natively for the part of the software that interacts with an SQL store. (Any NoSQL storage also must be carefully designed.) The way you predefined all your queries is very nice and manageable anyway. |
Cheers @xeoncross. ORMs may give a headstart, but in the long run, they almost always end up being inadequate. Easier to just write SQL than to learn an obtuse ORM language :) |
Another vote for MySQL. I can tolerate some performance downgrade to use MySQL. |
@hsluoyz As I wrote earlier, listmonk uses a number of Postgres specific features. While it is possible to build an abstraction layer to add support for multiple storage backends (and this may happen in the future), there are definitely no plans of adding MySQL or any other storage backend right now. There are other features that take priority. Thanks. |
I vote for MySQL as well! |
Listmonk looks great but the reason why we still stick to other paid products is that we don't want to maintain Postgres. Postgres requirement is a blocked for us. We run exclusively on MySQL. Adding support for MySQL would be great. |
Thanks @vladaman, but adding support for two large DBs is not feasible for a product like listmonk, unfortunately. If anything, the support should be for SQLite enabling it listmonk to be able to run with zero dependencies. On a slightly unrelated note, we find Postgres to be far more stable and far more easier to maintain. For non-massive DBs, it's pretty much install and forget! |
Can you split main package to cmd/listmonk
And other stuff provide like listmonk package for easy to integrate to other apps?
Also why you dont use something like xorm to abstract db access?
This can bring ability to use sqlite or mysql too
The text was updated successfully, but these errors were encountered: