gajus/slonik

False library comparisons in documentation

vitaly-t opened this issue · 7 comments

vitaly-t commented

You are making invalid statements about pg-promise in your comparison chapter.

  • Slonik does not allow to execute raw text queries. Slonik queries can only be constructed...

pg-promise escapes all values/parameters safely, through variables. And it features the most advanced query-formatting and escaping engine, which is fully customizable. There is no difference in that regard from this library, totally false statement.

  • Slonik implements interceptor API (middleware). Middlewares allow to modify connection handling, override queries and modify the query results

Did you copy the idea from pg-promise implementation of all this, and now claim that your library has it and pg-promise doesn't? That's just bad...

  • Slonik implements transaction nesting.

Are you s.-g me? pg-promise was the first library that implemented nested transactions and savepoints with automatic labeling and complete configuration. And it's been there for 5 years now. You took the idea, and now claim again your library has it, but pg-promise doesn't?

Please remove all those false statements.

gajus commented

Slonik does not allow to execute raw text queries. Slonik queries can only be constructed using sql tagged template literals. This design protects against unsafe value interpolation.

pg-promise escapes all values/parameters safely, through variables. And it features the most advanced query-formatting and escaping engine, which is fully customizable. There is no difference in that regard from this library, totally false statement.

My statement is factually correct:

  • Slonik does not allow text queries. Queries must be executed using sql tagged template literal.
  • Slonik does not allow anyway of intentionally or accidentally interpolating variables into the query other than through bindings constructed using sql tagged template literals.

pg-promise allows to execute any payload that is passed to query function.

Slonik implements interceptor API (middleware). Middlewares allow to modify connection handling, override queries and modify the query results

Did you copy the idea from pg-promise implementation of all this, and now claim that your library has it and pg-promise doesn't? That's just bad...

I am not familiar with pg-promise library enough to comment about similarities in implementation, and it has been over a year since I have written that section of the documentation. I have glanced through your library and do not see similar functionality provided.

Are you s.-g me? pg-promise was the first library that implemented nested transactions and savepoints with automatic labeling and complete configuration. And it's been there for 5 years now. You took the idea, and now claim again your library has it, but pg-promise doesn't?

Please share a reference to the documentation that supports this claim.

I apologise if I misrepresented your library in my comparison. You are welcome to contribute to Slonik, including changes to the documentation.

vitaly-t commented

Since I started this unpleasant topic, I feel like adding a punch line...

I have been working on PostgreSQL projects for many years now, and continue to do so. Most of the clients I work with use gigantic SQL all over the place. I'm talking real-world projects, not some cute-looking single-line example on your documentation page.

If I were to tell them to start placing all that huge SQL into JavaScript code, with ES6 template string formatting, they would think I've gone mad. Not only it is a monumental effort on its own, but it is completely non-maintainable, and a worthless endeavor.

Here's another crazy thought... I am currently working with a few crypto companies, who would change SQL files many times, and continue running multiple processes that use them, as the system picks up changes automatically. With your approach one has to shut down every process that uses the SQL. That would kill productivity for any large project.

I've said it before, and will say it again, ES6 template strings are worthless when it comes to real-world PostgreSQL projects.

I am not familiar with pg-promise library enough

I will accept that, if you please remove that comparison chapter, and not list pg-promise there at all, because clearly you do not know what you are talking about.

Please share a reference to the documentation that supports this claim.

Do you really think that I should now start providing links for all the false comparisons you've made? Please remove the comparison chapter, or any mentioning of pg-promise in your documentation.

  • 👍11
  • 👎1
gajus commented

I have blocked @vitaly-t because of his continuously pretentious and hostile tone.

No part of the documentation is meant to mislead others. It has been written with my best intention teach how to use Slonik and how it differs from other solutions. If parts of the documentation are inaccurate (or outdated), I will accept suggestions for an improvement.

  • 👎30
boromisp commented

To address the three points:

While I haven't used slonik before the transaction nesting in both libraries seems functionally equivalent.

The client-side query formatting is probably the main strength of pg-promise. It does not prevent shooting yourself in the foot, but it does provide a clearly separate place to put untrusted input and makes it easy to do the right thing.

There is a way to extend pg-promise objects (databases, tasks, etc.) with custom functionality, but it seems different from the slonik's middleware model (I haven't used either extensively, so it's hard to judge).

porsager commented

This is not fair @gajus. You are falsely presenting something another person spent huge amounts of energy and time on — and then expect that person not to have a problem with it.

It's easy to hide behind claims of pretentious and hostile responses, but have you considered your actions/replies might have prompted it?

If you don't want to take the time to check out pg-promise don't compare your library to it.

If you're going to block him and prevent him from stating his case, at least honor his request and remove the comparison!

  • 👍24
austince commented

We're a current user of pg-promise, though we're thinking of moving off of it as our use-case is simpler than the vast reconfigurability of pg-promise. We are considering many solutions, and slonik is one of them, but I agree with the others on this thread that @vitaly-t shared some very reasonable objections, and would vote for removing the comparison, as he has been a devoted maintainer for years.

I don't think the comparisons really do this library as much good as the controversies they are bound to start. Maybe reaching out to independent bloggers for a review would be a better way to get good comparisons?

I personally greatly appreciate you open sourcing this and devoting your time to being a good maintainer, but am not thrilled reading this thread and think it might deter others who are thinking of switching and appreciate the pg-promise library.

  • 👍5
gajus commented

@austince The documentation has been since updated to reflect Vitaly's objections. Namely: I have removed erroneous statement that implied that pg-promise does not support Promise nesting, and I have rephrased the other differences to reflect that pg-promise provides comparable functionality.

I am going to correct all erroneous statements when they are brought to my attention.

I am not going to remove comparison – having a comparison in the documentation enables new users to quickly grasp the trade offs and identify which is the right library for their use case.

  • 👍6