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

Suggestions #17

Closed
vtolstov opened this issue Sep 6, 2019 · 8 comments
Closed

Suggestions #17

vtolstov opened this issue Sep 6, 2019 · 8 comments
Labels
question Further information is requested

Comments

@vtolstov
Copy link

vtolstov commented Sep 6, 2019

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

@knadh
Copy link
Owner

knadh commented Sep 6, 2019

Can you split main package to cmd/listmonk

Will consider this. The re-usable and extensible parts are already packages and it's just HTTP handlers in the main package.

Also why you dont use something like xorm to abstract db access?

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

@knadh knadh added the question Further information is requested label Sep 6, 2019
@xeoncross
Copy link

xeoncross commented Oct 2, 2019

Most of listmonk's queries use CTEs extensively and they'd have to hand-written anyway.

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.

@knadh
Copy link
Owner

knadh commented Oct 3, 2019

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 :)

@knadh knadh closed this as completed Oct 24, 2019
@hsluoyz
Copy link

hsluoyz commented Feb 15, 2020

Another vote for MySQL. I can tolerate some performance downgrade to use MySQL.

@knadh
Copy link
Owner

knadh commented Feb 15, 2020

@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.

@sals9
Copy link

sals9 commented May 25, 2020

I vote for MySQL as well!

@vladaman
Copy link

vladaman commented Jan 3, 2023

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.

@knadh
Copy link
Owner

knadh commented Jan 3, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

6 participants