Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Project status #82

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

Closed
bartlomieju opened this issue Jan 26, 2020 · 10 comments
Closed

Project status #82

bartlomieju opened this issue Jan 26, 2020 · 10 comments

Comments

@bartlomieju
Copy link
Collaborator

I just wanted to leave a short information for anyone interested in this project.

It seems to be half dead, but that's not the case. A huge chunk of my time is now dedicated to the work in main Deno repo at the moment.

I still intend to put more work into this module but that will happen after Deno 1.0 is released.

@malthe
Copy link

malthe commented Mar 7, 2020

FYI over in TS-land I wrote and maintain a relatively complete pg-driver which can probably be made deno-compatible without too much difficulty: https://github.com/malthe/ts-postgres.

@slim-hmidi
Copy link

slim-hmidi commented May 5, 2020

@bartlomieju what is the roadmap of the module? are there any intention to develop functions for the majority of postgresql instructions and commands. Because creating a big query using query() will not an easy thing when the query is complex and contains many conditions. Do you have any idea about the future release or work to be done later?

@kluzzebass
Copy link
Contributor

@slim-hmidi It sounds like you're looking for a query builder or an ORM, which is probably not what this module is supposed to be.

@hayd
Copy link
Member

hayd commented May 8, 2020

e.g manyuanrong/dso#2

@slim-hmidi
Copy link

slim-hmidi commented May 8, 2020

@kluzzebass I don't think if in a big project with a big query contains a lot of conditions a developer will enjoy writing a text query then add so many args.
Personally, I find it not useful with big complex apps.
I don't know what's the intention of this module.

@bartlomieju
Copy link
Collaborator Author

@slim-hmidi this repository contains driver for PostgreSQL - ie. low level primitives that allow you to connect and talk to the DB. Drivers are necessary to create ORMs or other higher-level libraries like query builders (think Knex). I don't intend to add much "sugar" to the code base, it should be left to user libraries like dso that @hayd pointed out.

@qimingweng
Copy link

I wonder if it makes sense to merge resources with something like: https://github.com/porsager/postgres

It’s a pure JS project with no dependencies, so there would be some nodeJS APIs that need altered

I think it’s important to establish a best practice early, and perhaps it’s an opportunity to overtake pg, which is too big/standard and would need time to change.

@grantcarthew
Copy link

grantcarthew commented May 21, 2020

Please pin this issue. Also, a good postgres driver is rather urgent. I know, open source, not getting paid, do it yourself... I understand.

I looked at adding a case for NOTICE messages to fix #124 however got a little lost.

@grantcarthew
Copy link

Would it not be better to directly port the node-postgres project over to Deno? As you can see above, I have opened a discussion about this on the original repository.

@Soremwar
Copy link
Collaborator

It's almost a year now since I started mantaining deno_postgres, so I wanted to give an update on the project status and what has changed since this issue was opened:

  • Features and bug fixes have been somewhat constant, major releases take place within one or two months of difference and they are usually substantial. However many requested features are still pending and it's gonna take a while before the driver can be considered "fully featured", nevertheless all features required by most users are implemented and stabilized
  • I share the mindset of bartlomieju about the driver being minimal and not reaching ORM levels of abstraction, however I also consider that there are many features (such as transactions and pools) that can be built on top of the driver to provide a better developer experience and are worth the time investment
  • I'm not looking to copy or resemble any existing database library, and all existing APIs will represent my opinionated view on how a driver should be used. However I'm open to any suggestions that may provide any form of improvement on the driver, even if they mean changing existing APIs
  • Deno postgres must remain as lightweight as possible, so dependencies on third party libraries other than Deno's own std must have a good justification in order to be added to the driver
  • Deno postgres must remain competitive regarding user experience and performance. I want to advertise it as one of the best solutions out there regarding those two points, so this will be a focus in the upcoming months before the 1.0 release
  • At the moment of writing this, I have already marked all requested desired features as a milestone for 1.0. Anything requested or wanted after that point will likely have to wait to the next release after that before it can be addressed

@denodrivers denodrivers locked and limited conversation to collaborators Sep 29, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants