I want to thank you for your great work on this project. I have not had the same experience from any other package so I want you to know your work is greatly appreciated.
There have been so many instances where your work has saved me time and confusion. Where I have spent hours researching on the best and most future proof methods for a new implementation only to realize you have done the same and is already being used or ready to use out of the box. You have done the work to make sure all the best practices are baked-in and set-as-default.
All the best during this difficult time.
Thank you so so much @vitaly-t.
@Portur Thank you!!! Feature set in this library is indeed huge. However, the practice shows that not many developers are willing to read documentation, to understand what's available to them.
For example, support of external SQL files is one of the most powerful yet underused features. Also Custom Type Formatting, as another example.
I was asked a few times to add support for Nested Named Parameters. But from so much code I've seen on GitHub, nobody ever uses it, while it does add a lot of flexibility to values-parameters, especially from inside query files.
pg-promise-demo is also a good starting point that gets lost in translation quite often.
In all, for anyone willing to read documentation, a lot can be discovered, for the benefit of your project. As for the rest, it is their loss, there is only so much I can do here.
I think its good to take into account that most developers who know how to do what this package does, will do it themselves. Those who don't, will use your package and is what brought me here.
To show inexperienced developers multiple concepts and methods, to achieve something they don't even understand the benefit of, is maybe the main reason why they don't "read" the documentation.
I am sure they read the documentation (or more accurately, glance through), but when they need to eg, "get realtime events from postgres in nodejs", they don't know what they need, what to look for or where to start. So the documentation might mention how to use listen and notify but any developer using the package, or most developers, won't know what that entails or brings to their requirement. They won't understand that they need to use the robust example instead of adding the listener to the existing pool because they have no idea how a pool works, what happens when it disconnects, how to reconnect without downtime, etc.
I value your work immensely and have learned to firstly check the "Learn by example" pages before I write any code for what I intend to do, simply because I did it on my own, ran into issues & bugs and after sometime end up back here to check examples now that I better understand whats happening and whats broken.
Do what you do, don't change anything in pg-xxx. If you feel developers are losing out by not thoroughly reading through the docs first, maybe post more goal orientated examples that solve a general use case. I for one learn a lot from your robust examples and would miss them if they get replaced by more general examples.
I hope this provides some insight.
So the documentation might mention how to use
listenandnotify
It does here.
I meant if a developer comes across that they won't instinctively know what that functionality is, which is why it seems they don't "read the documentation". It was just an example to explain how most developers using your package aren't familiar with the term.
Luckily you explain it in the documentation and examples.
my code was a complete train wreck when I started with sequelize, then jumping into pg gave me even more headaches because it lacks bulk inserts etc but I am sooo happy to find a library that offers just the level without going into Knex or Objection type high level API but at the same time offers enough functionality and performance as pg with excellent documentation no less, truly amazing work!
@slidenerd There's also pg-promise-demo, which might be of help :wink: