Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Vitaly Tomilov
    @vitaly-t
    Ok, that link is no longer valid, as he of course deleted it. I was talking about this project - https://github.com/gajus/slonik
    He's been copying ideas from pg-promise, and then spreading BS, claiming the opposite.
    spacejack
    @spacejack
    Hi, I just tried upgrading to 10.2.0 and I got this error during npm install:
    > libpq@1.8.9 install /home/me/myproject/node_modules/libpq
    > node-gyp rebuild
    
    You need to install postgresql-server-dev-NN for building a server-side extension or libpq-dev for building a client-side application.
    gyp: Call to '/usr/bin/pg_config --libdir' returned exit status 1 while in binding.gyp. while trying to load binding.gyp
    This is on Ubuntu 19
    v9.x all worked fine
    spacejack
    @spacejack
    Any ideas? I mean I can install postgresql-server-dev but I'm not sure why I should need to for v10
    Vitaly Tomilov
    @vitaly-t
    @spacejack This has nothing to do with v10
    $ sudo apt-get install libpq-dev
    spacejack
    @spacejack
    Oh I guess there is a new pg-native dependency in v10 that is the cause.
    Vitaly Tomilov
    @vitaly-t
    @spacejack pg-promise does not have pg-native as a dependency.
    spacejack
    @spacejack
    Vitaly Tomilov
    @vitaly-t
    It is an independent module that you can install separately, in case you want pg-promise make use of the Native Bindings.
    H.F.S!!!! :angry: I broke it it during the last test+deployment! :cry:
    OMG, I am removing it immediately, and re-publishing!
    Thank you for pointing out!!!!
    spacejack
    @spacejack
    :thumbsup:
    Vitaly Tomilov
    @vitaly-t
    I hate this NPM auto-save feature!!!! :angry:
    spacejack
    @spacejack
    lol yeah...
    Vitaly Tomilov
    @vitaly-t
    I threw it in, I didn't even notice
    1 min, will fix it now.
    spacejack
    @spacejack
    Oh I see I guess you were testing with pg-native
    spacejack
    @spacejack
    sweet I'll give it a try
    Vitaly Tomilov
    @vitaly-t
    Yes, locally, but damn NPM auto-saved in, and I didn't notice.
    Happened in the past also.
    Should be all good now ;)
    Again. thank you for finding out about this! :thumbsup:
    spacejack
    @spacejack
    np, thanks for the quick fix
    Regarding that slonik package, I think it's a shame the way the dev is promoting it but at least it looks like he has made some changes to his docs: gajus/slonik@9b17e6d
    spacejack
    @spacejack
    I do think the template strings is a nice feature... I'm not sure if you would want to look into adapting that for pg-promise. I'd rather use this library since it's more mature.
    spacejack
    @spacejack
    Maybe even a 3rd party helper could turn sql\SELECT FROM "foo" WHERE "id" = ${id}`into['SELECT FROM "foo" WHERE "id" = $1', id]`
    Vitaly Tomilov
    @vitaly-t
    I asked him more than once to remove all that crap he wrote about pg-promise, but instead, he locked my account.
    As for ES6 template strings as formatting,...as I was explaining there...
    spacejack
    @spacejack
    ugh sorry, I don't know how to format those strings :(
    Vitaly Tomilov
    @vitaly-t
    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.
    And he pushes that ES6 template string formatting as an answer to all prayers. What a joke!
    spacejack
    @spacejack
    lol. But I was wondering if there's a way to add a template function that transforms template strings into regular pg-promise paramters. So your current interface still works as is.
    Anyway I haven't thought about it too much so it's probably not that easy
    Vitaly Tomilov
    @vitaly-t
    Here's just one example of real-world SQL people write, with variable formatting via pg-promise: https://github.com/NYCPlanning/zap-api/blob/develop/queries/assignments/index.sql
    What do you think guy would do to a suggestion to use ES6 template string instead?
    spacejack
    @spacejack
    Oh sure, I'm not saying it's for all use cases.
    My app has much shorter queries though
    And I wasn't suggesting deprecating the current API
    Vitaly Tomilov
    @vitaly-t
    Once you start building on top of the real app business logic, you will quickly find out that your SQL grows in size.
    And with ES6, you can't even document SQL!
    Look at that SQL example I just gave - it is full of inline documentation/comments, non of it can even exist inside ES6 template strings.
    But I was wondering if there's a way to add a template function that transforms... - yeah, I've never considered anything like that, didn't need to either.
    Vitaly Tomilov
    @vitaly-t
    One starts by writing SQL inside SQL files, then adding variables for the API. Not sure why someone would want to convert template strings into separate parameters.