We’re just expressing our opinions. And we can’t do much about it.
I feel orm should be pluggable. Right now postgres code feels like it’s an after thought. If I install frappe that supports 25 db engines, pyproject.toml will install 24 dependencies for unused engines.
I thought one of the primary reasons for adding PyPika was to support this exact case: multiple backend databases. If not, what was the point of PyPika?
As far as dependencies go, just make them optional. Plenty of other similar-sized Python applications do this. You all are smart: I’m sure you could figure out a way.
“Frappe supports Postgres” is misleading to new comers in general.
On this point, we are in full agreement.
I’m not asking for PR. Is your fork public? If someone needs they can refer?
PR’s are impractical for changes of this magnitude imo; so that’s good.
Yes, my forks of Frappe and ERPNext forks are always kept public.
Caveat 1 : I suggest not paying attention to them for at least a few weeks, until I finish the launch + bug fixes.
Caveat 2 : I only had 2-3 weeks to accomplish this. And once I move to Postgres, I’m never looking back. So I took plenty of shortcuts. Altering various code to make it Postgres-compatible, but not compatible with MariaDB anymore. Certainly the correct and proper thing would have been to replace them all with Pypika queries, or use frappe.db.multi_sql. But I had neither the time, nor motivation. So it’s not pretty. But it does work.
Raffael, I’ve been maintaining forks of Frappe and ERPNext for as long as I can remember. Probably all the way back to early 2017. There have been many, many benefits to doing so. A lot of which I’ve mentioned on the forums over the years. Without the ability to maintain forks and and solve my own problems, I would have abandoned ERPNext a long time ago.
Postgres is just the latest task or project that required altering the framework and ERP repositories directly.
I’m glad most people have no problems with MariaDB.
But for myself, it’s been the root cause of many headaches the past 4 years, across multiple clients and installations. The biggest challenges have been I/O locks that require restarting the service to undo. Poor query planning. Repeated occurrence of corrupt indexes. A completely unreliable Replication system. A tendency to deadlock. And although not a deal breaker, their physical backups are awkward and a pita.
And that’s not even mentioning all the benefits of Postgres over MariaDB in general.
Maybe Postgres will help me. Maybe it won’t. There’s only 1 way to find out.
This is what we keep saying is so great about open-source ERP, right? Take it, make it your own, do what you want with it.
The alternative is to sit here, and wait for other people to solve these problems for me. Not a good strategy.
I also would love to see Frappe adopt postgres. There have been some important incremental steps towards making that possible, such as the introduction of query builder, but it’s a massive, high-stakes undertaking. I can’t really imagine anyone putting forward the kind of time and resources involved anytime in the near future.
The mood lately also seems to be to prioritize stability over new features for ERPNext. That’s a positive choice, in my opinion, but it makes it even harder to justify devoting resources a massive rework like this.
As a long time (~25 years) Postgres user I am glad that you managed to hack it together in a short time.
I agree that moving away from frappe.db.sql and frappe.db.multi_sql to pypika queries would be the right way to move forward - not just for people using Postgres, but also for those who are using MariaDB as well.
I am confused as why Frappe is going in the opposite direction and actively trying to add SQLite support. There’s no public ticket that describes why the requirements or use case for this would be. SQLite is single threaded but fast, so it should be able to support more than one concurrent user, but who knows how many. There are no load tests in the existing test suite.
The intersection of businesses large enough to need an online/hosted ERP but small enough to be satisfied with a single threaded database is for practical purposes, zero.
Yes and I think that it could be a meaningful and adequate replacement for Redis and that licensing debacle, but still has less-than-ideal locking issues in that context.
General comment on influencing direction in open source projects (not limited to postgres)
Its been more than a decade since we have been running this project and we often see people complaining that they are unable to influence the direction of the project. Here is what they don’t get - influencing is a longer path. The goal should be to become a maintainer. They first have to make regular small contributions and help the existing maintainers. Then become part of the team that maintains. Be a good citizen, don’t break stuff, maitain the CI, help users. Then you get to have a say in the direction of the project
Yes you can say maintainers / Frappe should do this or that, but you don’t really know what every maintainer is doing. We have clearly said that it is really upto the maintainers to do what they think best. There are also several non-Frappe folks with maintainer rights - @snv, @revant_one@rmeyer
Then I see folks like @brian_pond@tmatteson who are very active, but choose not to help the maintainers and expect some kind of obligatory attention to their priorities. True, its open source and forking is always a good choice. Its sad though. Would have been great if they had chosen a different path.
Well, I cannot speak for every person who has ever complained on these forums.
But I can speak for myself and @tmatteson. We definitely do “get it”. This is not the first time you’ve shared your requirements and thoughts about contributions. We are -definitely- aware of your positions on this matter, Rushabh. They have been crystal clear.
… and expect some kind of obligatory attention to their priorities
This is untrue. We certainly don’t -expect- anything from you or the maintainers. Believe me, if there’s one thing I’ve learned? It’s to not expect anything from the project and its stewards.
Certainly I have frequently expressed disagreement, disappointment, and dissent. However, I definitely do not expect my words to have any influence or impact. That is not one of my goals when writing them.
Its sad though. Would have been great if they had chosen a different path.
I do agree, this is very sad indeed. I wonder if they have reasons?
I am sure this will benefit many v15 ERPNext users who would have to wait till v16 is available.
@brian_pond in our experience of having many types of customers, we have yet to find a reason to maintain a fork. Almost all of our customers are on frappecloud and custom apps with monkey patching always works out. This avoids maintaining code.
Would like to know some insights from you on why the forks are needed. There maybe something in there for us to learn from.
Who here is deploying ERPNext on k8s?
Who hear is using the CloudNative PG operator for PostgreSQL?
The traction and performance of the postresql kubernetes operators is huge reason to use it over other SQL options. I prefer to only have a single SQL operator on my clusters; less overhead and complexity…
PostreSQL is best option all around IMHO. It can be used to simplify a stack significantly, especially if you leverage the advanced features and extensions.
